Php package design

Video in TIB AV-Portal: Php package design

Formal Metadata

Php package design
Alternative Title
Php And Friends - Php package design
Title of Series
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date
Production Year

Content Metadata

Subject Area
Slide rule Functional (mathematics) Code Multiplication sign Software developer Menu (computing) Bit Independence (probability theory) Web 2.0 Writing Goodness of fit Latent heat Personal digital assistant Blog Software framework
Polymorphism (materials science) Cohesion (computer science) Group action Code Direction (geometry) Multiplication sign Execution unit Source code 1 (number) Set (mathematics) Solid geometry Encapsulation (object-oriented programming) Software bug Medical imaging Mechanism design Different (Kate Ryan album) Circle Social class Email Constraint (mathematics) Theory of relativity Software developer Electronic mailing list Bit Instance (computer science) Flow separation Degree (graph theory) Category of being Repository (publishing) Quicksort Spacetime Computer file Open source Divisor Connectivity (graph theory) Number Revision control Object-oriented programming Term (mathematics) Boundary value problem Äquivalenzprinzip <Physik> Task (computing) Forcing (mathematics) Cellular automaton Projective plane Line (geometry) Cohesion (computer science) Word Visualization (computer graphics) Personal digital assistant Network topology Blog
Group action User interface Code Multiplication sign Direction (geometry) 1 (number) Set (mathematics) Function (mathematics) Mereology Bookmark (World Wide Web) Web 2.0 Mathematics Sign (mathematics) Radio-frequency identification Different (Kate Ryan album) Computer configuration Algebraic closure Core dump Finitary relation File system Cuboid Endliche Modelltheorie Information security Social class Physical system Boss Corporation Service (economics) Theory of relativity Data storage device Stress (mechanics) Parallel port Instance (computer science) Flow separation Entire function Arithmetic mean Wave Website Text editor Right angle Annihilator (ring theory) Trail Game controller Implementation Computer file Dependent and independent variables Connectivity (graph theory) Adaptive behavior Drop (liquid) Rule of inference Graph coloring Code Number Product (business) Revision control Green's function Authorization Form (programming) Multiplication Graph (mathematics) Projective plane Code Software maintenance Cohesion (computer science) Cartesian coordinate system Mathematics Word Algebraic closure Personal digital assistant Blog Table (information) Library (computing)
Point (geometry) Building Code Graph (mathematics) Direction (geometry) Multiplication sign Code Formal language Independence (probability theory) Revision control Frequency Mathematics Different (Kate Ryan album) Energy level Circle Arrow of time Software framework Stability theory Social class Dependent and independent variables Graph (mathematics) Theory of relativity Forcing (mathematics) Moment (mathematics) Keyboard shortcut Bit System call Mathematics Data management Word Software Cycle (graph theory) Sinc function
Greatest element Implementation Code Graph (mathematics) Direction (geometry) Multiplication sign 1 (number) Code Product (business) Number Twitter Mathematics Algebraic closure Energy level Arrow of time Diagram Abstraction Äquivalenzprinzip <Physik> Stability theory Social class Task (computing) Graph (mathematics) Interface (computing) Moment (mathematics) Feedback Projective plane Code Price index Software maintenance Product (business) Mathematics Word Algebraic closure Personal digital assistant Website Cycle (graph theory) Table (information) Abstraction Library (computing)
Ocean current Implementation Divisor Code Workstation <Musikinstrument> Adaptive behavior Dimensional analysis Theory Number Neuroinformatik Mathematics Latent heat Different (Kate Ryan album) Computer configuration Googol Core dump File system Cuboid Diagram Office suite Computing platform Social class Area Namespace Projective plane Electronic mailing list Counting Bit Price index Instance (computer science) Cartesian coordinate system Software maintenance Affine space Connected space Word Data management Network topology Interpreter (computing) Configuration space Right angle Quicksort Abstraction Library (computing)
good morning everyone I'm just going to start it stand up look so I hope and everybody's sitting well and yet we should be able to learn to do this can anybody everybody hear me loud and clear also in the back yes alright so we trying a different set of with the lights and this 1 might look a little strange uh especially if you only look at my face but the slides are better off this way so yeah uh I hope that everybody can see that uh those 2 and my name is said not yes no work and this talk is about to package design and more specifically the principles underlying package design I where packages just any kind of reusable piece of code that you would like to share with yourself your company and your University of or the whole world you may know me from my blog it's about said PHP and symphony symphony is a web framework in case you didn't notice that it's a framework that I like particularly so I decided to come to dive into it and learn as low as I can as much as I can about it and it had to write articles about the framework itself and I can best use it so um after I was doing this for a couple of years I wrote this book it's called the with Symphony and give you some some more insight in the inner workings and some axons way of using it but also what's interesting for my own personal development is that in the last chapter is about moving away from the framework itself and trying to prepare your code for reuse and um while there are some some suggestions for the way so that you can prepare a code for such a reuse and and so as you can see I'm I'm I'm moving further and further away from the actual framework specific codon and always trying to look for ways in which more people than just the community would be I would be happy to use the code I write as in a way you could say that said for a long time I have been a tightly-coupled myself to this particular framework and I'm looking around a bit and and and also looking at at from that of a bit higher perspective at my own work so and this is the way I I envision it and it's just like in the writing code all they have regrouping that code into useful functions and then again regrouping those functions in the classes and and well then sometimes you may think that it's
it may be useful to to regroup those classes into even have bigger units or bigger components and those are called packages force
I wanna talk about packages there aren't many different kinds of them uh you can have private packages it for your own use or reuse and you can have a public packages you can have open source packages you can have a maybe closed source packages that you just a cell in some way or another and there may be straight boundaries so package may have a package definition file but it also may just be a set of files in your project and it may even be yeah just 1 particular in a space that you never thought of as a package would still can be considered to be a package and they're in the following everything I'm going to tell you about design principles and should be applicable to all kinds of factors these private and public open source closed-source source packages many of them so whenever we're looking for uh design principles for classes there are a lot of them and many you're very familiar as you you may already know about the solid principles and any other kind of design techniques like and encapsulation or polymorphism those those should be very familiar I think uh by this time but so for package designed there seems not to be any anything like that and there's no such thing as package design principles only classes and principles that even though packages are becoming more and more important in our in our everyday work uh I think many of you also try to try to use as many packages as possible that are of high quality but in a in a in a way that you don't have to write all the code yourself so it is important to know what should be considered to be a good package and um which packages are trustworthy can be relied on what so during this talk you will learn some things and some some some principles by which you can judge any existing package uh on its quality and in the funny thing is that I thought there would be no such thing as as package design principles nobody would have written about this and I never heard about it before and but I I came on this website about Uncle Bob outcome it's a website owned by Robert Martin and and uh I mean he's 1 that going the year the solid principles term but he also as 6 at package design principles and I must say it it's not all original work by him but it's a it's just some and expand on existing work and recombine those things and would nice names on it and so this is very useful I mean many people will be able to understand them these principles especially if you're somewhat used to object-oriented programming now when I when I stumbled upon them I thought well that there are a number of things so uh maybe I just dive into this and then start to research a bit about it the and then in the end I thought these these principles are very very useful and I think every pitch developer and fact every developer in the world should know about them uh in in case they want to really some code as reusable code so and yet I decided to write another book it's called principles of package and this is the is the the the particular goal I had in mind is to tell everybody about the ways you have to be thinking about and the writing your code therefore packages specifically so the question is always how can optimize the experience for the users of the package as well as for the maintainers and as the seem contradictory most of the time but that they really are not so if you apply the following and principles of correctly then the package will be better usable but it will we also also be better maintainable so that's that helps 2 kinds of people the by looking at the package design principles we can separate them into 2 groups the main group the 1st main group is a set of 3 principles and they are about cohesion and I think cohesion is something that's and every 1 of you will already know about it even though and then you you may not be able to explain the work property uh as of now at he is also about and combining things together belonging together and and if you're looking at the code you always have to address the self uh does this piece of code belong right here and shouldn't be it in some entirely different places and in other words it lasted to the to to label the the cohesive cohesiveness or the sense of belonging together of one's a group of classes for instance so if you look at these images you see that the blog I I I think they're very they should be able to represent packages in a way that the red package while clearly missed something that is in fact uh available in the real package so while there a cohesion problem there should move from the blue package to that package and as you can see there are several other green packages right there and they're so highly cohesive but they're still not very much together so it might be just best to move all those things into 1 package on the other 1 the i it's that has some cohesion problems as well I don't even know that well it it it tries to do so many things at the same time so we might just want to to create some nice smaller packages with just some examples from visual examples pardon there is something called coupling also for packages just as it is for classes and their indicates how different packages need each other to to do the work so you take a package you draw a line from 1 package to another 1 and you can judge those lines those dependency lines so you can always save and this is not a correct dependency and it is unsafe to depend on that package or maybe like like in this example there is a circle between us and the dependencies so and the green 1 depends on the orange 1 and it depends on the green 1 against it in a way you have to remove those said dependency and directions the so let's 1st take a look at the at the 1st 3 principles they are about cohesion what's important to keep in mind is that if you're talking about cohesion for packages you only have to look at 1 package at a time so cohesion is about 1 package not about its relation with other packages at all so the question is what's inside a package and doesn't belong there should maybe be another package for should be combined several packages into 1 to have better who is in the it and the 1st principle is called the release reuse equivalence principle and that's just a very very interesting name for and the idea that said the granule of reuse is degree you of release so you can you can read we use only as much code as it and properties release and any code that you release is reusable so there is that this goes both in both directions and the thing uh to to keep in mind is that if if you want to reuse some code you have to proper a proper properly release that code and it's no use if you release code using for instance and that sending an e-mail to a 1880 and and you say well this is a piece of code you can reuse but then that that is not the properties and it's not entirely useful for the other person and because ball any any bug fixes that that that did that you may have for them and they and they don't get that automatically so that there's so many things we have to take care of when you're releasing code and this principle sort of remind you of that and just a just a quick list of things you have to think of when you're releasing code and all then this is actually much longer and and I can talk about this for hours I think there's so many things you have to do whenever you releasing code as well 1 thing you have to take care of his separable version control the code so uh no send e-mails to each other it's just it has to be in a version control repository and you have to provide a proper metafiles like a license file and the readme file at least somehow explaining what the package is about this is supposed to be a to be to to do and you have to make sure that every file in the package is already available using some kind of offloading mechanisms and there should be almost no things and that a user has to before making use of the package and yes of course have a nice package definition to set of the requirements for a package maybe your package needs other packages to work I you need to think about version of constraints so you don't want to limit them to too much or that you know also don't want to work and make them to a free and so those kinds of things and in particular if you ever released code you have to be very careful about and backwards compatibility is something you all know off I think whenever you upgrade something and then something goes wrong I mean it we can just talk about the tree itself these things happen all the time and there lot as soon as you start using your own code you in this this is your task to to to make sure that nobody experiences such problems with your own code and then well you can also say that world but then you have to put a warning you're really file you're not going to maintain this in a way that maybe some people want have but I think I think most of you if you ever released code to be reused by other people and then they definitely want to provide backwards compatibility and this this alone can be a lot of work and and so the conclusion is read that if you don't have
time for that if you cannot properly guarantee that you're going to have to your package in a real product and nicely be aiding product and then well maybe and this doesn't sound for her friendly as you may have you you maybe should not release that that package or just a little note on top of the readme file saying this is very nice but it's it's experimental and I I'm not done not not going to take a lot of time to them to maintain it so am yet and at the same time this this doesn't mean that I want to and discourage you to packages that means of it's a great experience it's really nice to see people use your code in other projects and but you have to take proper care of it and there is a uh the in this way this is such actually about cohesion since it is very hard to maintain very large packages they may decide to go for a small package with just 1 very particular feature but just a suggestion then the 2nd cohesion principle is the common reuse principle it sets of classes that are used together are packaged together and so on all that this sounds very good I mean if you want to use several classes and have to instill several packages that that doesn't sound good but it's better if you have 1 packages containing those classes that you want to use together but at the same time if you take a package and you know that 1 class and and another 1 and you don't use them together necessary in your projects there's something wrong so the idea here is that if you use 1 package in Europe EU project you should be able to use every class of it and you should also use every every class of as soon as there are classes that does that make sense to be used separately from my from each other then it may be time to speed up the package so this this is meant to prevent you from putting everything that is reusable in 1 package the I 1 way in which you can spot packages that violate this principle is by looking at the features they contain and then there is a package smell which is called feature stratum I invented the word is myself so I can explain you what it means and stress just a parallel layers and of code in this case and looking at the colors of the classes in the package is see that the orange ones together in implement 1 particular feature and there is a set of green classes they and another feature and finally a set of red classes and the infant quite another feature and each of those features can be used separately and they have no interdependencies so actually indegree doesn't make sense to have them all in 1 package and you can see this in practice when someone needs to load this entire package in the project but use only 2 or 3 classes from it even though the itself the package itself contains maybe 20 classes so that's the packages and smell um 1 example is from my my actually favorites projects in projects and this simply security component it contains features for and in ACL access control and so on therefore features and which are needed by all the other features there's f for cross a request a forgery protection an HTTP our features to uh to support the logging using forms for instance and and and some other things but basically these components http require core but they can be used entirely separately so it only makes sense to have separate packages for them in and so this infinite maintainers did this they already split this package and it only makes sense because and it's not really about the the amount of bytes that you have to have on your desk where the amount of code that you include in your projects and even though in that can be a danger to it's more about and keeping track of changes so if you have a user for this security no components and and wall of course security is very important so they have to keep track of all the changes that occur within this this package and and well if if there were no separate packages for all of these features then we would have to upgrade the the main package all the time because of the important feature chip feature and fixes and while most of those changes should be relevant to you at all since you only use 1 small part of it and yes so it's it's important to to really speak those packages into multiple ones what just so so just like the the maintenance team already did for the symphony security component and then another sign off of packages for violating this principle is that some well when 1 class in the package needs another dependency then another class so there can be other packages that are only needed by a very small part of this 1 new package I had a great example would be and I think many libraries are a great example of this but for instance a file system abstraction package that I know and and have worked with it's called go for it and it contains all kinds of adapters to work with that particular file systems torches and to extract the the differences between them away so that you can't just say I want to store this file on an unknown file system and then the adapters that contain the the is the detailed implementations for that particular file system but the problem is of course that with so many editors most users will only pick 1 and use that in their system for instance Table store their files on drop box I'm sure that that's a good idea but if you do and then you probably are not going to store files in other place at the same time so it is very likely that you only use 1 of those 20 30 classes of this package and well why again is is bad but most of the upgrade changes made to this package are about adapters that you don't use so you have to keep upgrading the project even though it doesn't make sense to you end up writing a project is always dangerous there may always be changes and that you didn't know about which will break your own output so again create separate packages for this and uh make sure that so that you don't lie about dependencies are I mean it sounds amazing sons with harsh ahead for me to say lie but and this is the way that you can use the package definition file for PHP is composer file and instead of saying I require these packages for those particular lectures and this packages I suggest you install several other packages uh in case you want to use the door open the door the Dropbox adapters for instance and and this is totally be not true I mean the code in the package cannot be executed without and these dependencies so these are not not really suggested the presence or optional ones and they are actual require dependencies and and if you think about this there is maybe no such thing as an optional optional dependency is if you need it then you really need it if you don't need it then you don't so there's nothing in between and so in a way this this this this hides the true dependency graph from from site and the funny thing is that I talked to to the author of the library and he says I agree with you 100 % and the waves of Newfoundland plastic that was the that's just very nice and we set yeah we should have each adapter a separate package and each package should have its maintainer that would be great as well since um several people or 1 person cannot know everything about all these different houses so it's just really great to have separate maintainers for those actress and they will make sure that that that it has the best of the best ideas that are out there as still as you can as he says currently this can be difficult to achieve and I I agree with that too so you have to have a manageable of people working together so yes that maybe has to be some some kind of faith and golden 11 next the common closure principle and as you know from your code them there may be lots of external influences like pacman or sisters if you recognize that assesses 1 but well you're here code is is is influenced by many changes so sometimes well you may use and PHP version and then you upgraded and and well that that that that James itself already forces you to change your own code and which is an external influence also um if your boss comes in and says we have to change this then yes your code is going to change because this person asks you to do this in a particular thing and so whenever you maintain multiple packages you want to make sure that some uh the amount of that that the number of packages that you have to touch because of a required change is the smallest possible and otherwise you have to open all those packages make all those changes which wished nude versions of it and they will just be lower so just this you have to make sure that the change is limited to a small number of features and we can think for reasons of change reasons for change about and while phrases that the features changes and change for some kind of rule about the business changes may be um while a if you want they read some blog post but not by me by myself and then see all this should be done in this way I
I'm going to change this right now then that will cause a lot of changes over the code base as well and then you want to limit those at the number of changes to the smallest number possible also on which is C uh many times that 1 package contains a code for all kinds of application layers like code for the web templates like a command-line codes and model infrastructure and all kinds of things uh thrown together into 1 package and yet this gives problems as well so it's always good to to separate the those as well and to allow people to and I cannot use your templates in but instead only use your model for instance it can be very useful the next uh group of packages is about coupling and as I already said the coupling is about um looking at the relations between several packages so you take this worse package in the middle and try to drive out to to draw all the dependencies surrounding it dependencies in words and dependencies of what's found keep in mind tho that you cannot you can't analyze or inspect the entire package ecosystem that that would be just too much work and in fact it's all about and the package is actually installed in your project so you have to always take care that those dependency directions are proper and and what I proper depends ejections well will will that today so 1st of all
and the a cyclic dependencies principle tells us that we should have no cycles in our dependency graph and even though are maybe package managers will be able to uh to resolve the circular dependencies meaning that can the problem with that that you you may be able to fix that by just helping it's in a way to and point out those circles yourself and jet it will usually bring you a lot of trouble and and most particularly when you're trying to upgrade packages and um well for oratory least reason we use new versions of them the since if you want to read the release of version 1 or maybe that's a version 2 of your package and it needs and other packages uh version 3 maybe have but that package needs to have version 4 of another package but that's fair version for needs version 2 of your baggage then you end up waiting for each other releasing the actual next major version and so there's not a real solution for that uh you know you will never know if everything is going to work at once you have released all the versions since they cannot be installed properly at the moment so you have you will have to some kind of a big bang release where every packages and upgraded to a new major major version and then you just have to hope that it will work out and so in general I think that's an I'm sure many of you will agree with me that uh city dependencies are dangerous in at at at very low level at class level and but they are also dangers Pakistan and so am well this is just a nice quote and somebody is asking about and the package manager for PHP wouldn't be able to to solve secluded dependencies well it is able but yet he says and what in the end I just refactor my code had to remove this this particular codes and so on and it's very easy to remove these these cycles as well so mostly it's about uh regrouping packages have to depend on itself which is entirely safe out maybe there's another problem where you have to extract a new class and put it in its own package to it to invert the dependence directions and that should should not be a problem at all and then the last of the or the last 2 of the principles are about stability and it's it's really fascinating for me too and uh I mean I have been using stability as a word a was when I was talking about software but I never thought about this would mean actually and and well you could say that something is stable it's resistant to change but this never came to mind but it's really nice to to think about like that so that you know this better a person stable if they are and easily affected by things that are happening in their surroundings and so any external forces are not able to influence the same goes for a stable building it's not like the likely that such a building is going to collapse since it's just stable no there there are no reasons for it to change it will stand as is so and the funny thing is that an person well a person building a somewhat different from because of a package is stable when a it's unlikely by external forces and and the thing is that stability is not is not not an internal quality of the package but it's an excellent quality so external or other packages are able to influence the stability of the of a particular package it's interesting to note and it's also interesting to look at how the different kinds of relations that package can have with surrounding packages so 1st of all and this is a package and no other package depends on it so it can do anything it wants it can change at any time it likes uh so this should be considered an irresponsible package it has no responsibility to stay the same over a longer period of time the the and why these kinds of these are very nice since I had to when you the maintain you can change anything you like in and and nobody will even notice so that's just great at the same time we can look at this kind of
packages and say that it is a dependent package so the orange 1 has multiple dependencies it depends on many things so let's call it dependence and the problem with dependencies is that the as I already mentioned are and are able to change your code as well so when 1 of your dependencies changes it has a new upgrades of some some change some backwards incompatible changed probably then you are going to change because of that and there's no way you can you can prevent it if you want to use the new version you have to change your code as well of being dependent is a bit dangerous it it allows you are at it it makes you and well a bit in stable since you're likely to change because of external and changes and together these 2 combined and so your expected it is completely irresponsible it's also very dependent on this makes a very unstable package so the funny thing is that your expected while it it got really help itself you know just below the way that it is surrounded by packages and the way that them the dependence directions go make it remains stable package then looking at the other way around and this is an orange brackish another 1 and many packages are depending on its so the the could call this 1 the response or package and it shouldn't change all the time because then lots of all the packages should have to change to this is a problem of course with um the the Peachtree language but also framework packages there it's hard for them to make changes because everybody will be angry about the changes they have to make as well so in that way on these these packages tend to be very stable and not not make any big changes at all and because they feel responsible and they are then if you look at the the arrows down to what's other packages we can see that this packages completely independent there are no other packages that it needs to do its work and the and this also means that it's not likely to change because of other packages so did and when when it would have made dependencies it will be likely that that is 1 they need to change its own code but now there are no dependencies so no reason for change except are internally motivated once but these 2 combined because say that said the Orange package here is very you responsible it's also very independence and and this these 2 quantities of a package and make it very stable so it's not very likely that this package is going to change at all and it's just going to remain the same except well for the the the usual reasons but if you at least that sorry there was a short cut and I was made to for reasons
internally motivated so there are no external changes that might have might make this is stable if come the stable dépenses principle says that and when you have a and find that have well when you have labeled a package stable a in stable war somewhat in stable or somewhat stable you should draw a diagram of those packages and check if the direction of those arrows leads only to more stable packages so dependent directional stability as you can see at the top there is an irresponsible package there no packages depending on its still it is dependent on the green 1 and the green is also dependent on to some other packages and there's only 1 package depending on it so it's somewhere in between stable and in stable at the bottom there packages and that are only dependent upon but never depend on anything else so those contributed to the very stable so this is this this this this arrangement of packages and fully conforms to the the stable defenses principle but then this diagram shows a problem where there are several responsible packages those are also dependent on meaning they are in stable and then they depend on some packets that is well quite stable somewhere in between it's and that the green baggage depends on a package that has so many other dependencies which makes its in stable and so that the direction of stability is not uh downwards but then it goes up towards a lesson still packages and yet this this violates the principle I'm saying up and down which is not really relevant you could also have so we'll entire diagram upside down and that's there the convention here is to draw the more stable packages at the bottom and the idea that the more instill lectures at the top of that's that's why I'm saying up and also the final of principle is about that obstruction and we can nicely combine the the 2 so we have the stable dependence principle if you're drawing and the diagram packages from from in stable stable then the depends the arrows who only point downwards and the same goes for so as we'll see in a moment I'm a question for you I was more likely to change is that something that is concrete or something that's abstract concrete now the 1st answer is the right 1 and at y that I would that that it just is better but now what and that is something is a concrete if it contains the implementation details and it's the details it always change someone comes in and says we need to to to uh get on a number of things we need to use another library or something and yeah so that that is that is very concrete those details those have to be changed the abstract things usually stay the same and this is also the entire intensional Using abstract things in your code uh to to to move away all the the actual practical details from site and to depend on something that is likely to choose to stay the same as for a longer time so yes it what is more likely to change a class or interface when we consider a class to be concrete and then the interface in uh as abstract well then the interest is less likely to change them and the task is likely to change and so the next question would be uh where would we put and interfaces in what kind of packages stable or in stable and table at all right so yes and that is entirely too and since those interfaces are not going to change all the time we want them to be in packages that also or not not go to change all the time and since if and if an interface will be anarchy in a package that changes all the time then it would render the the stability quite useless so and this is what the stable abstractions principle tells us abstract should increase with stability if we draw the same diagram again and find some kind of a numeric indicator for the abstractness of the package that is to say and the number of interfaces versus the number of classes that would give a nice indication of it being a very um abstract or very concrete package and then if we draw all of those packages again we have to make sure that so we only depend on things that are more abstract and and yeah so battery while missing is light years to it's in there is a side missing and the site should should show you that the same kind of Pakistan diagram that with some indication of it being abstract or concrete well I think you can picture that in your mind or you have to because there is no concrete 1 alright so and we've seen the 6 principles there right now and that will just as as a way of of quickly and memorizing them and the first one was the reuse reuse equivalence principle and it says that you can only reuse codes that you actually can release as a product it makes no sense to reuse code and there's not released in any and says I will give you a lot of trouble especially in especially your users and the next 1 is a common reuse principle and it said that all code packages reuse at the same time if you find a package with a class of that that can be used separately as in a meaningful way then it should be split the common closure principle says that because in a package only changes for a few reasons for a while In this case for just 1 reason so you have to make sure that whenever you start modifying your code you have to touch the smallest number of possible and of existing packages basically dependencies doesn't there should be no cycles in the dependency graph alright that stable dependencies only depend on more stable packages so don't start depending on packages that have many dependencies themselves that will make your own package is stable and stable abstractions at the same time would
say that the more stable packages could also be more abstract ones and the more instable packages should be the more concrete ones so get the the concrete packages will contain lots of classes implementation details and then those will depend on abstract packages containing more interfaces right and well just 1 quick word of advice you cannot use all of them at the same time you cannot make your code and follow all of the all these principles um but if you keep them in mind I think the experience in general will be a nice 1 for you as a maintainer as well as for the user since you will have less problems with uh dependencies dead have troubles and it will be the easier to just pick 1 little package and use it's just like you want it to be and it will make in general your entire project more stable if you judge existing packages by the way they follow these basic design principles on the left rising had become by this book uh by me about the same subject on early public comment and I also have several of paper copies with me today so if you if you're interested in in this subjects and then come to me and ask them and and finally I would really like to have some feedback on this talk it's on joined in a budget you can see this joint in slashed 1 3 0 4 5 7 you can find me on twitter if you want to discuss something in what away and um well maybe there's a couple of minutes of question time left so anyone or it could just behind and at the level which is that but just look over there is that
but and of you and you will hear that all going to be thank you for a lot of this work the theory the in the the 1 of the things what you have to be on the list of the so you can and then you have a right right and so that so yeah right right and AP and uh I was thinking about how to do that and yet so and the question is about to and the debtor packages that I mentioned before the file system abstraction Avenue application you you need them only the abstract uh stuff over the accepted aspects of that and it's in your package you would depend on the and abstract packaged so that it should be the core of the core package of the file system library and and then the predicted should also have 1 or 2 and computer letters uh dependencies so you can you can just add the premise is that you like to use it all right they you know about this you make the the right and so uh again uh another question and a deposit would have to know about the concrete dependencies because the concrete ways in which it talks to and specific file systems yet I think this is no problem at all in the application is the is the most concrete thing about them uh your code and it contains all the configuration then all the details about how to connect with France's drop box if you want to use that and so we are on the application of why I would say it's no problem I if you creating a reusable application area that's maybe in the course platform or something and and then you would have to provide no concrete incantations again but you just have to ask for uh for users to do this and well then the peace be a package manager has something and it it it's called composer and it has an option to ask for package that that provide that is this is the provides key and you can ask for packages to provides an implementation for a file system for instance and so to look this up provides interpretation and the act and package maintainers can again label their packages and say that it provides a concrete implementation for a file system and after yeah so trees right thanks Taylor questions yeah thank for you you all you want to find out what right so the question is then if I start creating a new package then and it will be very hard to follow these advices although all these principles and which 1 is the most important or well then how would you deal with that and I think on reuse is very 1 the common reuse principle and I think this is the most important 1 because it tells you how do not put all kinds of different things in 1 package and and the most practical advice I would give is to start very small create 1 very small package with just a few classes on which offers 1 solution for something and then uh of course make it extensible so other people can create new adapters for it but yet you will have some some experience with mating the package and it it I think it should work out to for me it always has worked out to to pick just 1 small feature not trying to create 1 big application or that or office solutions for everybody the stock great things OK but not the way out of the world and you know what want the the knowledge the with the of the where the we idea and the question is how do you handle a package's ability so when you're when you're working for you when you do a trying to provide backward compatibility it's a real problem that everything in PHP is is out in the open so as to ensure that it contains 1 class or it might be possible that someone is using it and even though you think it's private to the package yet it how you go about changing that code and true and this is why it would be really great to have packages visibility as a sort of indicators of scopes uh for PHP itself uh when this is not going to happen for now I would see that you have to maybe document is something somewhere uh uh you should also use or you can use annotations were classes saying and that this is 1 that belongs to the official API so you say that at at API and this is this is a bit of a convention right now add 2 more classes and and methods to be well supported by you in your backwards compatibility promise that in a way so and there there are no real good but there are conventional ways to accomplish the same thing current has 1 thing 1 that's question I OK yes but you 2 of the and yet there there there are these metrics and remove my dimensions them as well as they are about the number of ingoing and outgoing connections and will just just calculating the ratio for that and it actually that simple so you just count the number of classes that just affinities going words and those going out divide those and and and that should be the instability and of the the old and now I it helps from package to package so and if you uh it doesn't take actually and the instability of all the packages into consideration it's is 1 number which is which is applies to 1 package and then you can draw the entire diagram and then all will show whether or not you have a by the principles and there is currently as of there's predict projects at the depends which allows you to analyze it classes in 1 is this the same way with fanouts Infineon's um but it doesn't work for us and actual composer packages so it only takes uh either namespaces were I lecture the at package station into consideration it will be really great to have a change in that package PD pens so that you can just analyze your entire project for these kinds of well I mean uh if you do it by hand it would be much to work and too much work yeah right and so I think that's it thank you and I'm what can I say if you