Principles of Package Design (PHPCon Poland 2015)
•
4 likes•1,517 views
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.
Recommended
Recommended
More Related Content
Viewers also liked
Similar to Principles of Package Design (PHPCon Poland 2015)
Similar to Principles of Package Design (PHPCon Poland 2015) (20)
More from Matthias Noback
More from Matthias Noback (20)
Recently uploaded
Recently uploaded (20)
Principles of Package Design (PHPCon Poland 2015)
- 1. Principles of Package Design How to create cohesive, stable packages Matthias Noback
- 2. Writing
- 3. A Year With Symfony leanpub.com/a-year-with-symfony
- 5. What we do
- 7. Class design
- 9. Principles of Package Design leanpub.com/principles-of-package-design
- 12. A - Cohesion principles Perspective: the package in isolation
- 13. ! 1 - The Release Reuse Equivalence Principle The granule of reuse is the granule of release
- 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. 1 - The Release Reuse Equivalence Principle The Rule of Three blog.codinghorror.com/rule-of-three/
- 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. 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. 2- The Common Reuse Principle Smell: Feature strata
- 19. 2- The Common Reuse Principle Example of feature strata: the Symfony Security Component
- 20. 2- The Common Reuse Principle Smell: Classes with different dependencies
- 21. 2- The Common Reuse Principle Example of different dependencies: Gaufrette
- 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. 2 - The Common Reuse Principle Leszek Prabucki's response
- 24. 3 - The Common Closure Principle Classes that change together are packaged together
- 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. 3 - The Common Closure Principle Smell: code for multiple application layers • Web User Interface • Command-line interface • Model • Infrastructure services
- 27. B - Coupling principles Perspective: the package in relation to other packages
- 28. 4 - The Acyclic Dependencies Principle The dependency graph of packages must have no cycles
- 29. 4 - The Acyclic Dependencies Principle
- 30. Stability Something is stable if it's resistant to change.
- 31. 5 - The Stable Dependencies Principle An irresponsible package
- 32. 5 - The Stable Dependencies Principle A dependent package
- 33. 5 - The Stable Dependencies Principle An instable package: irresponsible and dependent
- 34. 5 - The Stable Dependencies Principle A responsible package
- 35. 5 - The Stable Dependencies Principle An independent package
- 36. 5 - The Stable Dependencies Principle A stable package: responsible and independent
- 37. 5 - The Stable Dependencies Principle Depend in the direction of stability
- 38. 5 - The Stable Dependencies Principle Counter example
- 39. 6 - The Stable Abstractions Principle What is more likely to change? ! • Something concrete or something abstract? • A class or an interface?
- 40. 6 - The Stable Abstractions Principle Abstractness should increase with stability
- 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. 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. Principles of Package Design leanpub.com/principles-of-package-design/c/phpconpl
- 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