Presented at the Dutch Symfony Meetup

1. Principles of PHP Package Design
Object oriented design for packages
Matthias Noback - PHP developer and consultant
Dutch Symfony Meetup - 3/2/2014

2. Matthias Noback
Noback's Office
· PHP developer
· Consultancy, training, writing
· Clean code, TDD
2/33

3. A Year With Symfony
leanpub.com/a-year-with-symfony
3/33

4. Principles of PHP Package Design
leanpub.com/principles-of-php-package-design
4/33

5. Object oriented design
5/33

6. Class design
· Single Responsibility Principle
· Open Closed Principle
· Liskov Substitution Principle
· Interface Segregation Principle
· Dependency Inversion Principle
6/33

7. Package design
Cohesion
7/33

8. Package design
Coupling
8/33

9. Source: Robert Martin
Book: Agile Software Development, Principles, Patterns, and Practices
Articles: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
9/33

10. The Release Reuse Equivalency Principle
The granule of reuse is the granule of release
10/33

11. The Release Reuse Equivalency Principle
·
·
·
·
Version control and hosting
Composer package definition
Auto-loading
Semantic versioning
- Tags
- Backward compatibility
· Quality control
11/33

12. 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.
12/33

13. The Common Reuse Principle
Violation: Feature strata
13/33

14. The Common Reuse Principle
Symfony Security Component
Has multiple parallel features that can be used separately:
· Authentication (HTTP)
· Authorization (ACL)
· Session (CSRF)
(Has been fixed now by the way)
14/33

15. The Common Reuse Principle
Violation: Classes with different dependencies
15/33

16. The Common Reuse Principle
Monolog
Many different logging handlers:
· Not (re-)used together
· Each with different dependencies
16/33

17. The Common Closure Principle
Classes that change together are packaged together
17/33

18. The Common Closure Principle
Classes that change together are packaged together
Which external changes would be able to force a change in the package?
· The web framework changes
· The persistence library changes
· The application's features change
· The business rules change
· ...
18/33

19. The Common Closure Principle
Violation: being highly sensitive for changes in a dependency
F S e t u d eand J S e i l z r
ORsBnl
MSraie
Discussion on GitHub
A s t cand its filters
sei
19/33

20. The Common Closure Principle
Violation: code for multiple application layers
FSsrude
OUeBnl:
· Model
· View
· Controller
· Services
20/33

21. The Common Closure Principle
We need packages that are closed against changes in:
· The framework
· The persistence layer
21/33

22. The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles
22/33

23. The Acyclic Dependencies Principle
Composer
Composer can resolve cyclic dependencies
As a package maintainer you will be in trouble because of:
· Conflicting version requirements: inability to resolve versions
· Where do you start when you want to change the package?
23/33

24. The Stable Dependencies Principle
Instable package: irresponsible, dependent
24/33

25. The Stable Dependencies Principle
Stable package: responsible, independent
25/33

26. The Stable Dependencies Principle
Depend in the direction of stability
Packages with more dependencies depend on packages with less dependencies.
Those independent packages have to behave responsibly and not change all the
time.
26/33

27. The Stable Dependencies Principle
Depend in the direction of stability
"Stability" then equals "not easy to change" (versus volatility).
Hard to change packages should not depend on easy to change packages.
27/33

28. The Stable Abstractions Principle
Abstractness increases with stability
A package should be as abstract as it is stable.
28/33

29. The Stable Abstractions Principle
Abstractness increases with stability
A less stable package, should be also more concrete.
A more stable package, should also be more abstract.
29/33

30. The Stable Abstractions Principle
Abstractness increases with stability
The implementation details will change often
They belong in an unstable package.
The abstractions (interfaces mainly) will stay the same
They belong in a stable package.
30/33

31. The Stable Abstractions Principle
Violations: all over the place
Many packages offer both interfaces and implementations
It can be okay, but if you expect others to offer new implementations, you
should offer the interfaces separately.
E.g.:
· Assetic filters
· Monolog handlers
31/33

32. Summary
· Consider each package as a real product
· Put code in it that will all be reused at the same time
· Make sure it only needs to be changed for a small number of reasons
· Remove any cycles in the dependency graph
· Packages are only allowed to depend on more stable packages
· Stable packages are highly abstract, instable packages are highly concrete
32/33

33. Thank you
twitter
www
github
leanpub
@matthiasnoback
php-and-symfony.matthiasnoback.nl
github.com/matthiasnoback
leanpub.com/principles-of-php-package-design