Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Principles of PHP Package Design - DomCode, first monthly meeting

881 views

Published on

Slides for my talk "Principles of PHP Package Design" at the first monthly meeting of DomCode: http://www.meetup.com/DomCode/events/192964782/

Published in: Software
  • Be the first to comment

Principles of PHP Package Design - DomCode, first monthly meeting

  1. 1. Principles of PHP Package Design Objectoriented design for packages Matthias Noback - Noback's Office DomCode, first monthly meeting - 7/28/2014
  2. 2. First monthly meeting of DomCode 2/52
  3. 3. Also: congratulations to SweetlakePHP 3/52
  4. 4. Matthias Noback Noback's Office PHP developer Writer/speaker Proud father · · · 4/52
  5. 5. Blog php-and-symfony.matthiasnoback.nl 5/52
  6. 6. A Year With Symfony leanpub.com/a-year-with-symfony 6/52
  7. 7. Tight coupling Coupling to a framework 7/52
  8. 8. Code 8/52
  9. 9. Squiggly lines 9/52
  10. 10. Code 10/52
  11. 11. Packages There are many different kinds 11/52
  12. 12. Class design 12/52
  13. 13. Package design Nothing? butunclebob.com 13/52
  14. 14. Principles of PHP Package Design leanpub.com/principles-of-php-package-design 14/52
  15. 15. Package design Cohesion 15/52
  16. 16. Package design Coupling 16/52
  17. 17. A - Cohesion principles Perspective: the package in isolation 17/52
  18. 18. 1 - The Release Reuse Equivalence Principle The granule of reuse is the granule of release 18/52
  19. 19. 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 - - - · 19/52
  20. 20. 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. 20/52
  21. 21. 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. 21/52
  22. 22. 2- The Common Reuse Principle Smell: Feature strata 22/52
  23. 23. 2- The Common Reuse Principle Example of feature strata: the Symfony Security Component 23/52
  24. 24. 2- The Common Reuse Principle Smell: Classes with different dependencies 24/52
  25. 25. 2- The Common Reuse Principle Example of different dependencies: Gaufrette 25/52
  26. 26. 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", ... }, ... } 26/52
  27. 27. 2 - The Common Reuse Principle Leszek Prabucki's response 27/52
  28. 28. 3 - The Common Closure Principle Classes that change together are packaged together 28/52
  29. 29. 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 ... · · · · · 29/52
  30. 30. 3 - The Common Closure Principle Smell: code for multiple application layers Web User Interface Command-line interface Model Infrastructure services · · · · 30/52
  31. 31. B - Coupling principles Perspective: the package in relation to other packages 31/52
  32. 32. 4 - The Acyclic Dependencies Principle The dependency graph of packages must have no cycles 32/52
  33. 33. 4 - The Acyclic Dependencies Principle 33/52
  34. 34. Stability Something is stable if it's resistant to change. 34/52
  35. 35. 5 - The Stable Dependencies Principle An irresponsible package 35/52
  36. 36. 5 - The Stable Dependencies Principle A dependent package 36/52
  37. 37. 5 - The Stable Dependencies Principle An instable package: irresponsible and dependent 37/52
  38. 38. 5 - The Stable Dependencies Principle A responsible package 38/52
  39. 39. 5 - The Stable Dependencies Principle An independent package 39/52
  40. 40. 5 - The Stable Dependencies Principle A stable package: responsible and independent 40/52
  41. 41. 5 - The Stable Dependencies Principle Depend in the direction of stability 41/52
  42. 42. 5 - The Stable Dependencies Principle Counter example 42/52
  43. 43. 6 - The Stable Abstractions Principle What is more likely to change? Something concrete or something abstract? A class or an interface? · · 43/52
  44. 44. 6 - The Stable Abstractions Principle Abstractness should increase with stability 44/52
  45. 45. 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.- 45/52
  46. 46. Word of advice You can't maximize them all at the same time. Keep them in mind while you are working on a package. 46/52
  47. 47. Principles of PHP Package Design leanpub.com/principles-of-php-package-design I'm impressed. — Robert C. Martin 47/52
  48. 48. Principles of PHP Package Design Get a 10 dollar discount: http://leanpub.com/principles-of-php-package-design/c/domcode 48/52
  49. 49. Questions? feedback joind.in/11580 twitter @matthiasnoback leanpub leanpub.com/principles-of-php-package-design 49/52
  50. 50. Image courtesy Clean Coders GitHub BitBucket Packagist PoEAA But Uncle Bob Robert Martin · · · · · · · 50/52
  51. 51. 52/52

×