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 Package Design (PHPCon Poland 2015)

1,114 views

Published on

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.

Published in: Software

Principles of Package Design (PHPCon Poland 2015)

  1. 1. Principles of Package Design How to create cohesive, stable packages Matthias Noback
  2. 2. Writing
  3. 3. A Year With Symfony leanpub.com/a-year-with-symfony
  4. 4. Tight coupling
  5. 5. What we do
  6. 6. Packages many different kinds
  7. 7. Class design
  8. 8. Package design Nothing? butunclebob.com
  9. 9. Principles of Package Design leanpub.com/principles-of-package-design
  10. 10. Package design Cohesion
  11. 11. Package design Coupling
  12. 12. A - Cohesion principles Perspective: the package in isolation
  13. 13. ! 1 - The Release Reuse Equivalence Principle The granule of reuse is the granule of release
  14. 14. 1 - The Release Reuse Equivalence Principle • Version control and hosting • Composer package definition • Meta-files • Auto-loading ! • Semantic versioning • Branches • Tags • Backward compatibility • Quality control
  15. 15. 1 - The Release Reuse Equivalence Principle The Rule of Three blog.codinghorror.com/rule-of-three/
  16. 16. 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.
  17. 17. 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.
  18. 18. 2- The Common Reuse Principle Smell: Feature strata
  19. 19. 2- The Common Reuse Principle Example of feature strata: the Symfony Security Component
  20. 20. 2- The Common Reuse Principle Smell: Classes with different dependencies
  21. 21. 2- The Common Reuse Principle Example of different dependencies: Gaufrette
  22. 22. 2- The Common Reuse Principle Different 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 S "doctrine/dbal": "to use the Doctrine DBAL adapter", "microsoft/windowsazure": "to use Microsoft Azure Blob Storage a "ext-zip": "to use the Zip adapter", "ext-apc": "to use the APC adapter", ... },
  23. 23. 2 - The Common Reuse Principle Leszek Prabucki's response
  24. 24. 3 - The Common Closure Principle Classes that change together are packaged together
  25. 25. 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 • ...
  26. 26. 3 - The Common Closure Principle Smell: code for multiple application layers • Web User Interface • Command-line interface • Model • Infrastructure services
  27. 27. B - Coupling principles Perspective: the package in relation to other packages
  28. 28. 4 - The Acyclic Dependencies Principle The dependency graph of packages must have no cycles
  29. 29. 4 - The Acyclic Dependencies Principle
  30. 30. Stability Something is stable if it's resistant to change.
  31. 31. 5 - The Stable Dependencies Principle An irresponsible package
  32. 32. 5 - The Stable Dependencies Principle A dependent package
  33. 33. 5 - The Stable Dependencies Principle An instable package: irresponsible and dependent
  34. 34. 5 - The Stable Dependencies Principle A responsible package
  35. 35. 5 - The Stable Dependencies Principle An independent package
  36. 36. 5 - The Stable Dependencies Principle A stable package: responsible and independent
  37. 37. 5 - The Stable Dependencies Principle Depend in the direction of stability
  38. 38. 5 - The Stable Dependencies Principle Counter example
  39. 39. 6 - The Stable Abstractions Principle What is more likely to change? ! • Something concrete or something abstract? • A class or an interface?
  40. 40. 6 - The Stable Abstractions Principle Abstractness should increase with stability
  41. 41. Summary Reuse/release equivalence principle Reuse only code that you can release as a product. Common reuse principle All code in a package is reused at the same time. Common closure principle Code in a package only changes for a few reasons. Acyclic dependencies principle No cycles in the dependency graph. Stable dependencies principle Only depend on more stable packages. Stable abstractions principle More stable packages are also more abstract.
  42. 42. Word of advice You can't maximize them all at the same time. ! Keep them in mind while you are working on a package.
  43. 43. Principles of Package Design leanpub.com/principles-of-package-design/c/phpconpl
  44. 44. Questions? @matthiasnoback joind.in/16212 Thank you!
  45. 45. Images • http://cleancoders.com/ • https://github.com/ • https://bitbucket.org/ • https://packagist.org/ • http://martinfowler.com/eaaCatalog/ • http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • http://blog.8thlight.com/uncle-bob/2014/05/14/ TheLittleMocker.html

×