Slides for my talk at the Community Day of Laracon Europe 2014. Talk abstract With many great tools available for sharing packages of PHP code, it is now up to you as a developer to design these packages well. You have to decide what to put in a package, when to split a package and on what other packages you can safely depend. You will learn how to make good decisions about your package design and release reliable, highly usable and therefore highly esteemed packages of PHP code.

1. Principles of PHP Package Design
Objectoriented design for packages
Matthias Noback - Noback's Office
Laracon Europe/Amsterdam - 8/28/2014

2. Matthias Noback
Noback's Office
PHP developer, consultant
Writer, speaker
Proud father
·
·
·
2/50

3. Blog
php-and-symfony.matthiasnoback.nl
3/50

4. A Year With Symfony
leanpub.com/a-year-with-symfony
4/50

5. Tight coupling
Coupling to a framework
5/50

6. Code
6/50

7. Squiggly lines
7/50

8. Code
8/50

9. Packages
There are many different kinds
9/50

10. Class design
10/50

11. Package design
Nothing?
butunclebob.com
11/50

12. Principles of PHP Package Design
leanpub.com/principles-of-php-package-design
12/50

13. Package design
Cohesion
13/50

14. Package design
Coupling
14/50

15. A - Cohesion principles
Perspective: the package in isolation
15/50

16. 1 - The Release Reuse Equivalence Principle
The granule of reuse is the granule of release
16/50

17. 1 - The Release Reuse Equivalence Principle
Version control and hosting
Composer package definition
Meta-files
Auto-loading
·
·
·
·
Semantic versioning
Quality control
·
Branches
Tags
Backward compatibility
-
-
-
·
17/50

18. 1 - The Release Reuse Equivalence Principle
If you don't have the time to turn your reusable code into a proper package...
Don't release it.
18/50

19. 2- The Common Reuse Principle
Classes that are used together are packaged together
If you use one class of a package,
you will use all its other classes too.
19/50

20. 2- The Common Reuse Principle
Smell: Feature strata
20/50

21. 2- The Common Reuse Principle
Example of feature strata: the Symfony Security Component
21/50

22. 2- The Common Reuse Principle
Smell: Classes with different dependencies
22/50

23. 2- The Common Reuse Principle
Example of different dependencies: Gaufrette
23/50

24. 2- The Common Reuse Principle
Different dependencies: Gaufrette
{
"name":"knplabs/gaufrette",
...
"suggest":{
"knplabs/knp-gaufrette-bundle":"tousewithSymfony2",
"dropbox-php/dropbox-php":"tousetheDropboxadapter",
"rackspace/php-opencloud":"touseOpencloudadapter",
"herzult/php-ssh":"touseSFtpadapter",
"phpseclib/phpseclib":"tousePhpseclibSftpadapter",
"aws/aws-sdk-php":"tousetheAmazonS3adapter",
"amazonwebservices/aws-sdk-for-php":"tousethelegacyAmazonS3adapters",
"doctrine/dbal":"tousetheDoctrineDBALadapter",
"microsoft/windowsazure":"touseMicrosoftAzureBlobStorageadapter",
"ext-zip":"tousetheZipadapter",
"ext-apc":"tousetheAPCadapter",
...
},
...
} 24/50

25. 2 - The Common Reuse Principle
Leszek Prabucki's response
25/50

26. 3 - The Common Closure Principle
Classes that change together are packaged together
26/50

27. 3 - The Common Closure Principle
Reasons for change
The application's features change
The business rules change
The web framework's best practices change
The persistence library's configuration changes
...
·
·
·
·
·
27/50

28. 3 - The Common Closure Principle
Smell: code for multiple application layers
Web User Interface
Command-line interface
Model
Infrastructure services
·
·
·
·
28/50

29. B - Coupling principles
Perspective: the package in relation to other packages
29/50

30. 4 - The Acyclic Dependencies Principle
The dependency graph of packages must have no cycles
30/50

31. 4 - The Acyclic Dependencies Principle
31/50

32. Stability
Something is stable if it's resistant to change.
32/50

33. 5 - The Stable Dependencies Principle
An irresponsible package
33/50

34. 5 - The Stable Dependencies Principle
A dependent package
34/50

35. 5 - The Stable Dependencies Principle
An instable package: irresponsible and dependent
35/50

36. 5 - The Stable Dependencies Principle
A responsible package
36/50

37. 5 - The Stable Dependencies Principle
An independent package
37/50

38. 5 - The Stable Dependencies Principle
A stable package: responsible and independent
38/50

39. 5 - The Stable Dependencies Principle
Depend in the direction of stability
39/50

40. 5 - The Stable Dependencies Principle
Counter example
40/50

41. 6 - The Stable Abstractions Principle
What is more likely to change?
Something concrete or something abstract?
A class or an interface?
·
·
41/50

42. 6 - The Stable Abstractions Principle
Abstractness should increase with stability
42/50

43. Summary
Reuse/release equivalence principle
Common reuse principle
Common closure principle
Acyclic dependencies principle
Stable dependencies principle
Stable abstractions principle
·
Reuse only code that you can release as a product.-
·
All code in a package is reused at the same time.-
·
Code in a package only changes for a few reasons.-
·
No cycles in the dependency graph.-
·
Only depend on more stable packages.-
·
More stable packages are also more abstract.-
43/50

44. Word of advice
You can't maximize them all at the same time.
Keep them in mind while you are working on a package.
44/50

45. Principles of PHP Package Design
leanpub.com/principles-of-php-package-design
I'm impressed. — Robert C. Martin
45/50

46. Principles of PHP Package Design
Get a 10 dollar discount:
http://leanpub.com/principles-of-php-package-design/c/laracon
46/50

47. Questions?
feedback joind.in/11685
twitter @matthiasnoback
leanpub leanpub.com/principles-of-php-package-design
47/50

48. Image courtesy
Clean Coders
GitHub
BitBucket
Packagist
PoEAA
But Uncle Bob
Robert Martin
·
·
·
·
·
·
·
48/50

49. 50/50