16. The Common Closure Principle
Classes that change together are packaged together
Ask yourself which packages would change when:
The web framework changes
The persistence library changes
The application's features change
The business rules change
...
·
·
·
·
·
16/44
17. The Common Closure Principle
Classes that change together are packaged together
Example: FOSUserBundle- too much library code
Example: FOSRestBundleand JMSSerializerBundle- a dangerous alliance
17/44
18. The Common Reuse Principle
Classes that are used together are packaged together
If you use a class inside a package, you will (most likely) use (all) other classes
inside it too.
18/44
19. The Common Reuse Principle
Classes that are used together are packaged together
Example: FOSRestBundleand the QueryParamFetcher
Example: Monologand its handlers
Example: Asseticand its filters
Example: NelmioSecurityBundleand its listeners
19/44
21. The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles
Create a dependencies diagram:
clue/graph-composer
21/44
22. The Stable Dependencies Principle
Depend in the direction of stability
"Stability" equals "not easy to change" (versus volatility).
Hard to change packages should not depend on easy to change packages.
22/44
23. The Stable Dependencies Principle
Depend in the direction of stability
Dependencies between packages are dependencies by class:
Count number of dependencies out (C-out)
Count number of dependencies in (C-in)
I = C-out / (C-in + C-out)
23/44
24. The Stable Dependencies Principle
Depend in the direction of stability
E.g. 2 / (0 + 2) = 1(only out), so 1is very dependent, therefore instable
E.g. 0 / (3 + 0) = 0(only in), so 0is independent, therefore stable
24/44
25. The Stable Dependencies Principle
Depend in the direction of stability
Packages with more dependencies depend on packages with less dependencies.
These are less likely (because difficult) to change, since many other packages
depend on them.
25/44
26. The Stable Dependencies Principle
Depend in the direction of stability
Stable packages are called responsible (they should not be easy to change),
independent (only depended upon) packages.
Instable packages are called irresponsible (because easily changed) and
dependent (on more stable packages).
26/44
27. The Stable Abstractions Principle
Abstractness increases with stability
A package should be as abstract as it is stable.
A stable package (with less dependencies out than in), should have an equal
ratio of abstract versus total amount of classes.
27/44
28. The Stable Abstractions Principle
Abstractness increases with stability
Stable package: difficult to change. It has more dependencies in than out.
Given the Dependency Inversion Principle, packages will depend on other
packages because those contain abstract classes and interfaces, which adds
stability to their design.
28/44
29. The Stable Abstractions Principle
Abstractness increases with stability
A = C-abstract / (C-concrete + C-abstract)
No abstract classes, just concrete classes: A = 0
No concrete classes, just abstract classes: A = 1
29/44
30. The Stable Abstractions Principle
Abstractness increases with stability
Combine Iand Ain a graph.
30/44
31. The Stable Abstractions Principle
Abstractness increases with stability
When you plot these ratios you will see:
I = 0(stable) and A = 1(abstract) = (0, 1)(top-left corner)
I = 1(instable) and A = 0(concrete) = (1, 0)(bottom-right corner)
31/44
32. The Stable Abstractions Principle
Abstractness increases with stability
Everything in between should be in proportion.
A less stable package, should be also more concrete.
A more stable package, should also be more abstract.
32/44
33. The Stable Abstractions Principle
Abstractness increases with stability
On the other end of the spectrum are some strange packages:
I = 1(instable) and A = 1(abstract) = (1, 1)(top-right)
A package with no dependents, only dependencies, but very abstract
nonetheless.
I = 0(stable) and A = 0(concrete) = (0, 0)(bottom-left)
A package that has no dependencies, only dependents, and nevertheless has
only concrete classes.
33/44
35. The Rule of Three
From Facts and Fallacies of Software Engineering:
Therearetwo"rulesofthree"in[software]reuse:
Itisthreetimesasdifficulttobuildreusablecomponentsassingleuse
components,andareusablecomponentshouldbetriedoutinthreedifferent
applicationsbeforeitwillbesufficientlygeneraltoacceptintoareuse
library.
35/44
36. The Rule of Three
Effort
Project packages: 1:1
Written ony for this project (like modules for account management, blog, etc.).
36/44
37. The Rule of Three
Effort
Library package: 1:1or 3:2
For common needs, written for this project, but reusable in other projects.
37/44
38. The Rule of Three
Effort
Open sourced library package: 2:1
38/44
39. The Rule of Three
Effort
An entire reusable project (like Sylius): 3:1
(Or parts of it.). Within a well-known structure, offer end-to-end functionality,
while making it easy to extend/change behavior.
39/44
42. A Year With Symfony
When you work with Symfony2:
You need to understand the framework very well
You need to be very good at dependency injection
You will need a good project structure
You need to do be very well aware of any possible security issues
You should develop for reusability
·
·
·
·
·
42/44
