Dutch Symfony Meetup - Principles of PHP Package Design

33 %
67 %
Information about Dutch Symfony Meetup - Principles of PHP Package Design
Technology

Published on March 6, 2014

Author: matthiasnoback

Source: slideshare.net

Description

Presented at the Dutch Symfony Meetup

Principles of PHP Package Design Object oriented design for packages Matthias Noback - PHP developer and consultant Dutch Symfony Meetup - 3/2/2014

Matthias Noback Noback's Office · PHP developer · Consultancy, training, writing · Clean code, TDD 2/33

A Year With Symfony leanpub.com/a-year-with-symfony 3/33

Principles of PHP Package Design leanpub.com/principles-of-php-package-design 4/33

Object oriented design 5/33

Class design · Single Responsibility Principle · Open Closed Principle · Liskov Substitution Principle · Interface Segregation Principle · Dependency Inversion Principle 6/33

Package design Cohesion 7/33

Package design Coupling 8/33

Source: Robert Martin Book: Agile Software Development, Principles, Patterns, and Practices Articles: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 9/33

The Release Reuse Equivalency Principle The granule of reuse is the granule of release 10/33

The Release Reuse Equivalency Principle · · · · Version control and hosting Composer package definition Auto-loading Semantic versioning - Tags - Backward compatibility · Quality control 11/33

The Common Reuse Principle Classes that are used together are packaged together If you use a class inside a package, you will (most likely) use (all) other classes inside it too. 12/33

The Common Reuse Principle Violation: Feature strata 13/33

The Common Reuse Principle Symfony Security Component Has multiple parallel features that can be used separately: · Authentication (HTTP) · Authorization (ACL) · Session (CSRF) (Has been fixed now by the way) 14/33

The Common Reuse Principle Violation: Classes with different dependencies 15/33

The Common Reuse Principle Monolog Many different logging handlers: · Not (re-)used together · Each with different dependencies 16/33

The Common Closure Principle Classes that change together are packaged together 17/33

The Common Closure Principle Classes that change together are packaged together Which external changes would be able to force a change in the package? · The web framework changes · The persistence library changes · The application's features change · The business rules change · ... 18/33

The Common Closure Principle Violation: being highly sensitive for changes in a dependency F S e t u d eand J S e i l z r ORsBnl MSraie Discussion on GitHub A s t cand its filters sei 19/33

The Common Closure Principle Violation: code for multiple application layers FSsrude OUeBnl: · Model · View · Controller · Services 20/33

The Common Closure Principle We need packages that are closed against changes in: · The framework · The persistence layer 21/33

The Acyclic Dependencies Principle The dependency graph of packages must have no cycles 22/33

The Acyclic Dependencies Principle Composer Composer can resolve cyclic dependencies As a package maintainer you will be in trouble because of: · Conflicting version requirements: inability to resolve versions · Where do you start when you want to change the package? 23/33

The Stable Dependencies Principle Instable package: irresponsible, dependent 24/33

The Stable Dependencies Principle Stable package: responsible, independent 25/33

The Stable Dependencies Principle Depend in the direction of stability Packages with more dependencies depend on packages with less dependencies. Those independent packages have to behave responsibly and not change all the time. 26/33

The Stable Dependencies Principle Depend in the direction of stability "Stability" then equals "not easy to change" (versus volatility). Hard to change packages should not depend on easy to change packages. 27/33

The Stable Abstractions Principle Abstractness increases with stability A package should be as abstract as it is stable. 28/33

The Stable Abstractions Principle Abstractness increases with stability A less stable package, should be also more concrete. A more stable package, should also be more abstract. 29/33

The Stable Abstractions Principle Abstractness increases with stability The implementation details will change often They belong in an unstable package. The abstractions (interfaces mainly) will stay the same They belong in a stable package. 30/33

The Stable Abstractions Principle Violations: all over the place Many packages offer both interfaces and implementations It can be okay, but if you expect others to offer new implementations, you should offer the interfaces separately. E.g.: · Assetic filters · Monolog handlers 31/33

Summary · Consider each package as a real product · Put code in it that will all be reused at the same time · Make sure it only needs to be changed for a small number of reasons · Remove any cycles in the dependency graph · Packages are only allowed to depend on more stable packages · Stable packages are highly abstract, instable packages are highly concrete 32/33

Thank you twitter www github leanpub @matthiasnoback php-and-symfony.matthiasnoback.nl github.com/matthiasnoback leanpub.com/principles-of-php-package-design

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Home — PHP & Symfony

Dutch Symfony Meetup - Principles of PHP Package Design from matthiasnoback. I was very happy to see that the package design concepts and principles were ...
Read more

Symfony User Group Meetup - 6th o March 2013 - Symfony ...

Thursday 6th of March will be the 8th Symfony User Group NL meetup! (#sfugnl). The evening starts at 19.00 at Oracle in Utrecht (Hertogswetering), ...
Read more

About coding dojos, the Symfony meetup and my new book ...

Dutch Symfony Meetup - Principles of PHP Package Design from matthiasnoback. I was very happy to see that the package design concepts and principles were ...
Read more

Package Design | LinkedIn

Package Design. Packaging is a multifaceted discipline. It involves not only the actual act of packaging and preparing a product for shipment, but also ...
Read more

SweetLakePHP - Meetups

Raffle: PHP Design Patterns ... Principles of PHP Package Design ... But at the Dutch PHP Conference '13, ...
Read more

“php” jobs - Stack Overflow

Comprehensive benefits package; PHP Web ... We are a design firm so a keen sense of design principles is ... (Dutch: HBO/WO) PHP and MySQL do ...
Read more

matthiasnoback - HubSlide

... Symfony Live London 2014 The Bundle system is one of the greatest and most powerful ... Slides for my talk "Principles of PHP Package Design" at th... ...
Read more

BredaPHP (Breda) - Meetup

It is a bi-monthly meetup on the last thursday of ... Join the PHP community in ... //joind.in/search?keyword=Bredaphp. Primary language of the event: Dutch.
Read more