Principles of PHP Package Design
Object oriented design for packages
Matthias Noback - PHP developer and consultant
Dutch ...
Matthias Noback
Noback's Office
· PHP developer
· Consultancy, training, writing
· Clean code, TDD

2/33
A Year With Symfony

leanpub.com/a-year-with-symfony

3/33
Principles of PHP Package Design

leanpub.com/principles-of-php-package-design

4/33
Object oriented design

5/33
Class design
· Single Responsibility Principle
· Open Closed Principle
· Liskov Substitution Principle
· Interface Segrega...
Package design
Cohesion

7/33
Package design
Coupling

8/33
Source: Robert Martin
Book: Agile Software Development, Principles, Patterns, and Practices
Articles: http://butunclebob.c...
The Release Reuse Equivalency Principle
The granule of reuse is the granule of release

10/33
The Release Reuse Equivalency Principle
·
·
·
·

Version control and hosting
Composer package definition
Auto-loading
Sema...
The Common Reuse Principle
Classes that are used together are packaged together
If you use a class inside a package, you w...
The Common Reuse Principle
Violation: Feature strata

13/33
The Common Reuse Principle
Symfony Security Component
Has multiple parallel features that can be used separately:
· Authen...
The Common Reuse Principle
Violation: Classes with different dependencies

15/33
The Common Reuse Principle
Monolog
Many different logging handlers:
· Not (re-)used together
· Each with different depende...
The Common Closure Principle
Classes that change together are packaged together

17/33
The Common Closure Principle
Classes that change together are packaged together
Which external changes would be able to fo...
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
...
The Common Closure Principle
Violation: code for multiple application layers
FSsrude
OUeBnl:

· Model
· View
· Controller
...
The Common Closure Principle
We need packages that are closed against changes in:
· The framework
· The persistence layer
...
The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles

22/33
The Acyclic Dependencies Principle
Composer
Composer can resolve cyclic dependencies
As a package maintainer you will be i...
The Stable Dependencies Principle
Instable package: irresponsible, dependent

24/33
The Stable Dependencies Principle
Stable package: responsible, independent

25/33
The Stable Dependencies Principle
Depend in the direction of stability
Packages with more dependencies depend on packages ...
The Stable Dependencies Principle
Depend in the direction of stability
"Stability" then equals "not easy to change" (versu...
The Stable Abstractions Principle
Abstractness increases with stability
A package should be as abstract as it is stable.

...
The Stable Abstractions Principle
Abstractness increases with stability
A less stable package, should be also more concret...
The Stable Abstractions Principle
Abstractness increases with stability
The implementation details will change often
They ...
The Stable Abstractions Principle
Violations: all over the place
Many packages offer both interfaces and implementations
I...
Summary
· Consider each package as a real product
· Put code in it that will all be reused at the same time
· Make sure it...
Thank you
twitter
www
github
leanpub

@matthiasnoback
php-and-symfony.matthiasnoback.nl
github.com/matthiasnoback
leanpub....
Upcoming SlideShare
Loading in …5
×

Dutch Symfony Meetup - Principles of PHP Package Design

9,093 views

Published on

Presented at the Dutch Symfony Meetup

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,093
On SlideShare
0
From Embeds
0
Number of Embeds
3,635
Actions
Shares
0
Downloads
20
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Dutch Symfony Meetup - Principles of PHP Package Design

  1. 1. Principles of PHP Package Design Object oriented design for packages Matthias Noback - PHP developer and consultant Dutch Symfony Meetup - 3/2/2014
  2. 2. Matthias Noback Noback's Office · PHP developer · Consultancy, training, writing · Clean code, TDD 2/33
  3. 3. A Year With Symfony leanpub.com/a-year-with-symfony 3/33
  4. 4. Principles of PHP Package Design leanpub.com/principles-of-php-package-design 4/33
  5. 5. Object oriented design 5/33
  6. 6. Class design · Single Responsibility Principle · Open Closed Principle · Liskov Substitution Principle · Interface Segregation Principle · Dependency Inversion Principle 6/33
  7. 7. Package design Cohesion 7/33
  8. 8. Package design Coupling 8/33
  9. 9. Source: Robert Martin Book: Agile Software Development, Principles, Patterns, and Practices Articles: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 9/33
  10. 10. The Release Reuse Equivalency Principle The granule of reuse is the granule of release 10/33
  11. 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. 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. 13. The Common Reuse Principle Violation: Feature strata 13/33
  14. 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. 15. The Common Reuse Principle Violation: Classes with different dependencies 15/33
  16. 16. The Common Reuse Principle Monolog Many different logging handlers: · Not (re-)used together · Each with different dependencies 16/33
  17. 17. The Common Closure Principle Classes that change together are packaged together 17/33
  18. 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. 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. 20. The Common Closure Principle Violation: code for multiple application layers FSsrude OUeBnl: · Model · View · Controller · Services 20/33
  21. 21. The Common Closure Principle We need packages that are closed against changes in: · The framework · The persistence layer 21/33
  22. 22. The Acyclic Dependencies Principle The dependency graph of packages must have no cycles 22/33
  23. 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. 24. The Stable Dependencies Principle Instable package: irresponsible, dependent 24/33
  25. 25. The Stable Dependencies Principle Stable package: responsible, independent 25/33
  26. 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. 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. 28. The Stable Abstractions Principle Abstractness increases with stability A package should be as abstract as it is stable. 28/33
  29. 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. 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. 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. 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. 33. Thank you twitter www github leanpub @matthiasnoback php-and-symfony.matthiasnoback.nl github.com/matthiasnoback leanpub.com/principles-of-php-package-design

×