The document outlines key principles of package design, emphasizing cohesion, coupling, and stability in software development. It highlights six core principles: the release reuse equivalence principle, common reuse principle, common closure principle, acyclic dependencies principle, stable dependencies principle, and stable abstractions principle. The author advises balancing these principles when designing packages to enhance code maintainability and usability.

1. Principles of Package Design
Howtocreatecohesive,stablepackages
Matthias Noback - Noback's Office
FOSDEM - 1 Feb 2015

2. Writing
php-and-symfony.matthiasnoback.nl
2/46

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

4. Tight coupling
Coupling to a framework
4/46

5. Code
5/46

6. Packages
There are many different kinds
6/46

7. Class design
7/46

8. Package design
Nothing?
butunclebob.com
8/46

9. Principles of Package Design
leanpub.com/principles-of-package-design
9/46

10. Package design
Cohesion
10/46

11. Package design
Coupling
11/46

12. A - Cohesion principles
Perspective: the package in isolation
12/46

13. 1 - The Release Reuse Equivalence Principle
The granule of reuse is the granule of release
13/46

14. 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
-
-
-
·
14/46

15. 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.
15/46

16. 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.
16/46

17. 2- The Common Reuse Principle
Smell: Feature strata
17/46

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

19. 2- The Common Reuse Principle
Smell: Classes with different dependencies
19/46

20. 2- The Common Reuse Principle
Example of different dependencies: Gaufrette
20/46

21. 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",
...
},
...
}
21/46

22. 2 - The Common Reuse Principle
Leszek Prabucki's response
22/46

23. 3 - The Common Closure Principle
Classes that change together are packaged together
23/46

24. 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
...
·
·
·
·
·
24/46

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

26. B - Coupling principles
Perspective: the package in relation to other packages
26/46

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

28. 4 - The Acyclic Dependencies Principle
28/46

29. Stability
Something is stable if it's resistant to change.
29/46

30. 5 - The Stable Dependencies Principle
An irresponsible package
30/46

31. 5 - The Stable Dependencies Principle
A dependent package
31/46

32. 5 - The Stable Dependencies Principle
An instable package: irresponsible and dependent
32/46

33. 5 - The Stable Dependencies Principle
A responsible package
33/46

34. 5 - The Stable Dependencies Principle
An independent package
34/46

35. 5 - The Stable Dependencies Principle
A stable package: responsible and independent
35/46

36. 5 - The Stable Dependencies Principle
Depend in the direction of stability
36/46

37. 5 - The Stable Dependencies Principle
Counter example
37/46

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

39. 6 - The Stable Abstractions Principle
Abstractness should increase with stability
39/46

40. 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.-
40/46

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

42. Principles of Package Design
leanpub.com/principles-of-package-design
42/46

43. Questions?
twitter @matthiasnoback
feedback joind.in/13057
leanpub leanpub.com/principles-of-package-design
43/46

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

45. 46/46