Principles of PHP Package Design - DomCode, first monthly meeting

download Principles of PHP Package Design - DomCode, first monthly meeting

of 51

  • date post

    27-Aug-2014
  • Category

    Software

  • view

    133
  • download

    2

Embed Size (px)

description

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

Transcript of Principles of PHP Package Design - DomCode, first monthly meeting

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