IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

https://github.com/domnikl/DesignPatternsPHP

Definició de patró

Common solutions for programming problems are called patterns/Design patterns
Les solucions que s'utilitzen de forma comuna per a resoldre problemes de programació s'anomenen patrons o patrons de disseny

aka paradigms

Tipus de patrons de disseny

Bàsicament podem categoritzar-los en tres tipus:

Resources:

Conceptes

Llista de patrons de disseny


Altres relacionats:

Llista de anti-patterns

Resources:

Programació orientada objectes

SOLID

SOLID és un acrònim de Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion introduit per Michael Feathers per fer referència als primers 5 principis definit per Robert C. Martin (aka uncle Bob) per al disseny de programari orientat a objectes.

L'objectiu d'aquest principis és aconseguir que els programes creats seguint aquests principis siguin més fàcils de mantenir i estendre en el futur. SOLID són doncs unes guies de treball que s'apliquen durant el desenvolupament de programari per tal de refactoritzar el codi fins que sigui més llegible, comprensible i extensible. És part d'una estratègia per al desenvolupament àgil i adaptatiu.

  • S | SRP: Single responsibility principle. Una classe ha de tenir una sola responsabilitat. També es diu que només existeix un possible potencial canvique afecti la especificació de la classe) o que una classe ha de tenir una i sol una raó per canviar.
  • O | OCP: Open/Closed principle. Les entitats de programari (per exemple classes) han d'estar obertes a la extensió però tancades a les modificacions.
  • L | Liskov substitution principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
  • I | ISP: Interface segregation principle. Many client-specific interfaces are better than one general-purpose interface.
  • D | DIP: Dependency inversion principle. one should “Depend upon Abstractions. Do not depend upon concretions.

Recursos:

Single Responsibility principle

Una gràfica exemple de la repartició típica de responsabilitats en una aplicació:

HighLevelDesign.png

Podeu trobar un exemple pas a pas (en anglès) at/ You could find a step by step example at:

See also SOLID principles example with Laravel section  Single Responsibility Principle

Archive: Notes sobre la preparació de l'exemple Single Responsibility Principle example with Laravel

Recursos

Open/Closed principle

Lema:

IMPORTANT: Software entities should be OPEN for extension but CLOSED for modification

Com?

Separate extensible behaviour behind a interface and flip de dependencies

o vegeu també el patró de disseny:

Strategy Design Pattern [1]

Exemple incorrecte:

https://github.com/acacha/solid_laravel/blob/stupid_case_s/app/InvoiceReport.php

El métode show:

 public function show(){
        return "<strong>" . $this->invoice->totalAmmount . " </strong>";
    }

No està ni molt menys tancat a modificacions ja que per exemple l'haurem de modificar segur si volem mostrar la sortida en format text en comptes de HTML o per exemple per a una API en format XML/Json i tampoc tenim la classe preparada/oberta a extensions és a dir preparada per ampliar el seu comportament (saber mostrar no només en HTML sinó també en altre formats). La sol·lució és utilitzar interfícies i invertir les dependències:

Separate extensible behaviour behind a interface and flip de dependencies

La sol·lució:

Nou mètode show que depen d'una interfície (per exemple l'anomenem InvoiceShowInterface)

 public function show(InvoiceShowInterface $i){
        return $i->show($this->invoice);
    }

On InvoiceShowInterface:

 interface InvoiceShowInterface {
    public function show($invoice);
 }

I podem tindrà múltiples implementacions, per exemple HTML:

class InvoiceShowHtml implements InvoiceShowInterface {

    public function show($invoice)
    {
        return "<strong>" . $invoice->totalAmmount . " </strong>";
    }
}

i text:

class InvoiceShowText implements InvoiceShowInterface {

    public function show($invoice)
    {
        return "total: " . $invoice->totalAmmount;
    }
}

Resources:

Strategy Design Pattern
Strategy Design Pattern fa ús del Polimorfisme/polymorphism en OOP

strategy.png

L'exemple:

https://laracasts.com/series/whip-monstrous-code-into-shape/episodes/9

És un molt bon exemple de com i quan identificar la possibilitat d'aplicar aquest patró

Recursos:

Template Method Design Pattern

Vegeu Template Method Design Pattern

Recursos:

OCP in the SOLID Context

As we progress with these tutorials, we can put each new principle in the context of the already discussed ones. We already discussed the Single Responsibility (SRP) that stated that a module should have only one reason to change. If we think about OCP and SRP, we can observe that they are complementary. Code specifically designed with SRP in mind will be close to OCP principles or easy to make it respect those principles. When we have code that has a single reason to change, introducing a new feature will create a secondary reason for that change. So both SRP and OCP would be violated. In the same way, if we have code that should only change when its main function changes and should remain unchanged when a new feature is added to it, thus respecting OCP, will mostly respect SRP also.

This does not mean that SRP always leads to OCP or vice versa, but in most cases if one of them is respected, achieving the second one is quite simple.

Liskov substitution principle

Interface segregation principle

Dependency inversion principle

IMPORTANT: No confondre Dependency Inversion with Dependency Injection tenen certa relació però són conceptes diferents!

El principi Dependency inversion principle es basa en:

Depends on abstractions not on concretions

és a dir:

Dependre d'abstraccions i no pas de concrecions

Normalment en programació les Abstraccions s'implementen mitjançant Interfícies i Classes abstractes i les concrecions són classes que implementen les interfícies i pot ser que heretin de classes abstractes.

I amb quin objectiu? Doncs implementar el que s'anomena:

Decoupling code o desacoblament de codi

El concepte d'spaghetti code està relacionat amb el concepte de desacoblament de codi ja que precisament el codi espagueti és un codi altament acoblat és a dir que és difícil de modificar parts específiques o components del codi sense necessitat de modificar altres components relacionats (és diu que aquest components estan altament acoblats) de la mateixa forma que no és fàcil separar un espagueti (noodle) del plat d'espagueti.

Un altre exemple interessant és el dels instruments elèctrics, el cablejat de llum i els endolls (sockets). Vegeu la transparència 32 de [2]:

171754551762223.jpg

Recursos:

FIRST

Resources:

SOLID on angular

https://github.com/johnpapa/angular-styleguide

Dependency Inversion

Sovint és un concepte relacionat amb el de Service Container, vegeu també Laravel Service Container.

Vegeu:

Development


Programming languages

PHP

Frameworks:

Javascript

Angular

See AngularJS and:

https://github.com/johnpapa/angular-styleguide

Android

Android Design patterns

Software craftsmanship

Vegeu Software craftsmanship

Laravel

Vegeu també

Enllaços externs