Design Pattern

Informazioni generali da tenere presente in quanto sviluppatore.

ARGOMENTI GENERICI

Termini ed argomenti generici per creazione di codice:

Design Pattern

Indubbiamente importanti! Dato che ve ne sono un’infinità al piu numerabile, elenco solo quelli che reputo piu importanti:

  • reactor , implementato ad esempio nella gemma EventMachine di ruby
  • setter injection e interface injection
  • factory pattern
  • singleton pattern
  • strategy pattern
  • observer pattern e pub/sub pattern (per le differenze vedi questo breve ma esplicativo articolo)

Vedi questo tutorial semplice e immediato:

https://it.phptherightway.com/pages/Design-Patterns.html

Altri path interessanti sono visualizzabili al link

Vari esempi

qui si possono trovare validi esempi di design pattern e refactor:

Altro sito (https://deviq.com):

Altro:

DESIGN SPECIFICI

Repository Pattern

Tra le teorie lette, credo che una delle migliori interpretazioni consti nel supporre che questo pattern lavori in ottica di dominio, ovvero che i suoi metodi gestiscano le entità, e che quindi esso non debba occuparsi di svolgere direttamente query a DB e serializzazioni: per quello potrebbe andar bene un adapter.

Command Query Segregation

Vedi https://www.culttt.com/2015/01/14/command-query-responsibility-segregation-cqrs/

NOT PATTERNS

Quelli di seguito non sono dei veri e propri pattern, ma use cases che comunque possono essere interessanti, anche e solo a livello accademico.

Natural Language Simulation

non so bene quale sia il termine relmente corretto per riferirsi a questo caso (e quindi non so come cercarlo “nell’internet”). Mi riferisco a una serie i classi che servono per costriuire dei linguaggi naturali, come ad esempio i query builder come quello offerto da Eloquent (Laravel), che simila il costrutto nativo del linguaggio di query $qb->select()->where()->orWhere()->limit(). Probabilmente il pattern più attinente a questa casistica è il Builder.

Un caso pratico interessante potrebbe essere l’uso delle conditions infatti quando si costruiscono un’insieme di condizioni dentro agli if, stiamo simulando di molto il linguaggio naturale (letto così e fa così).

Qui un esempio banale di classe di condizione: considerando che sostanzialmente ogni condizione deve offrire un booleano, ed inoltre ipotizzando anche l’associatività con parentesi (`a and not b and (c or d) or e), un esempio di “condition builder” che implementa questo potrebbe essere

<?php
$cb = new ConditionsBuilder();
$cond = $cb->condition(ClassCondA)->and()->not()->condition(ClassCondB)->and()->condition(function(ConditionBuilderInterface $cb2){
    return $cb2->contition(ClassCondC)->or()->condition(ClassCondD);
})->or()->condition(ClassCondE);
$isOk = $cond->check();
$cb->reset(); // or get new $cb2 = $cb->new(); or clone the actual $cb->clone(); 
echo $cond;

se poi implementasse un _toString() come ipotizzato, diverrebbe fantastico anche al fine di debug.

Poi la cosa ancora migliore sarebbe anche associargli un Lexer (lessico) per verificare che la query sia costruita secondo specifiche regole, ad esempio due congiunzioni logiche consecutive ->or()->and()-> o che termini con ->not() dovrebbe essere considerato inconsistente!

Interessante potrebbe essere anche un print dei risultati booleani, così da capire come ogni singola condizione passata fosse true o false (con pretty print ad esempio);

Vedi qui sotto per il Lexer.

il concetto di Conditions potrebbe sposarsi bene anche coi Validators, che potrebbero essere i wrapper di un insieme di Conditions;

Lexer

Qui un esempio base di Token (singola componente del linguaggio), Lexer e Parser che effettivamente può essere messo in aggiunta a tutti i pacchetti che prevedano una creazione di un builder proprio di linguaggio (query builder ad esempio), così da verificare a priori varie inconsistenze:

Expression

Sempre ricollegato a questo tema di conversione tra gestione a classi e uso di un linguaggio logico, abbiamo le espressioni, ma contrariamente a quanto visto sopra, tutto passare da linguaggio nativo a costrutto in php:

PHP USAGE

Utilizzo dei Traits

Articolo interessante che illustra come Laravel utilizza alcuni Trait, e il design concettuale col quale implementarli. Molto bellino:

https://andy-carter.com/blog/using-laravel-s-eloquent-traits

Gestione Exception

Laravel Multi Tenant

Code Samples:

/developer/design-pattern/