Principles of PHP Package Design - Laracon Europe (Amsterdam) 2014
49
Principles of PHP Package Design Object oriented design for packages Matthias Noback - Noback's Office Laracon Europe/Amsterdam - 8/28/2014
-
Upload
matthiasnoback -
Category
Technology
-
view
648 -
download
0
description
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.
Transcript of Principles of PHP Package Design - Laracon Europe (Amsterdam) 2014
Principles of PHP Package DesignObject oriented design for packages
Matthias Noback - Noback's OfficeLaracon Europe/Amsterdam - 8/28/2014
Matthias NobackNoback's Office
PHP developer, consultantWriter, speakerProud father
···
2/50
Tight couplingCoupling to a framework
5/50
Code
6/50
Squiggly lines
7/50
Code
8/50
PackagesThere are many different kinds
9/50
Class design
10/50
Package designNothing?
butunclebob.com
11/50
Principles of PHP Package Design
leanpub.com/principles-of-php-package-design
12/50
Package designCohesion
13/50
Package designCoupling
14/50
A - Cohesion principlesPerspective: the package in isolation
15/50
1 - The Release Reuse Equivalence PrincipleThe granule of reuse is the granule of release
16/50
1 - The Release Reuse Equivalence Principle
Version control and hostingComposer package definitionMeta-filesAuto-loading
····
Semantic versioning
Quality control
·BranchesTagsBackward compatibility
---
·
17/50
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
2- The Common Reuse PrincipleClasses 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
2- The Common Reuse PrincipleSmell: Feature strata
20/50
2- The Common Reuse PrincipleExample of feature strata: the Symfony Security Component
21/50
2- The Common Reuse PrincipleSmell: Classes with different dependencies
22/50
2- The Common Reuse PrincipleExample of different dependencies: Gaufrette
23/50
2- The Common Reuse PrincipleDifferent dependencies: Gaufrette
{ "name": "knplabs/gaufrette", ... "suggest": { "knplabs/knp-gaufrette-bundle": "to use with Symfony2", "dropbox-php/dropbox-php": "to use the Dropbox adapter", "rackspace/php-opencloud" : "to use Opencloud adapter", "herzult/php-ssh": "to use SFtp adapter", "phpseclib/phpseclib": "to use PhpseclibSftp adapter", "aws/aws-sdk-php": "to use the Amazon S3 adapter", "amazonwebservices/aws-sdk-for-php": "to use the legacy Amazon S3 adapters", "doctrine/dbal": "to use the Doctrine DBAL adapter", "microsoft/windowsazure": "to use Microsoft Azure Blob Storage adapter", "ext-zip": "to use the Zip adapter", "ext-apc": "to use the APC adapter", ... }, ...} 24/50
2 - The Common Reuse PrincipleLeszek Prabucki's response
25/50
3 - The Common Closure PrincipleClasses that change together are packaged together
26/50
3 - The Common Closure PrincipleReasons for change
The application's features changeThe business rules changeThe web framework's best practices changeThe persistence library's configuration changes...
·····
27/50
3 - The Common Closure PrincipleSmell: code for multiple application layers
Web User InterfaceCommand-line interfaceModelInfrastructure services
····
28/50
B - Coupling principlesPerspective: the package in relation to other packages
29/50
4 - The Acyclic Dependencies PrincipleThe dependency graph of packages must have no cycles
30/50
4 - The Acyclic Dependencies Principle
31/50
Stability
Something is stable if it's resistant to change.
32/50
5 - The Stable Dependencies PrincipleAn irresponsible package
33/50
5 - The Stable Dependencies PrincipleA dependent package
34/50
5 - The Stable Dependencies PrincipleAn instable package: irresponsible and dependent
35/50
5 - The Stable Dependencies PrincipleA responsible package
36/50
5 - The Stable Dependencies PrincipleAn independent package
37/50
5 - The Stable Dependencies PrincipleA stable package: responsible and independent
38/50
5 - The Stable Dependencies PrincipleDepend in the direction of stability
39/50
5 - The Stable Dependencies PrincipleCounter example
40/50
6 - The Stable Abstractions PrincipleWhat is more likely to change?
Something concrete or something abstract?A class or an interface?
··
41/50
6 - The Stable Abstractions PrincipleAbstractness should increase with stability
42/50
SummaryReuse/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
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
Principles of PHP Package Design
leanpub.com/principles-of-php-package-design
I'm impressed. — Robert C. Martin
45/50
Principles of PHP Package Design
Get a 10 dollar discount:
http://leanpub.com/principles-of-php-package-design/c/laracon
46/50
Questions?
feedback joind.in/11685
twitter @matthiasnoback
leanpub leanpub.com/principles-of-php-package-design
47/50
Image courtesyClean CodersGitHubBitBucketPackagistPoEAABut Uncle BobRobert Martin
·······
48/50
50/50
