Principles of PHP Package Design - Laracon Europe (Amsterdam) 2014

Preview:

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.

Citation preview

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

Blogphp-and-symfony.matthiasnoback.nl

3/50

A Year With Symfony

leanpub.com/a-year-with-symfony

4/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

50/50

Recommended