Il Builder pattern separa la costruzione di un oggetto complesso dalla sua rappresentazione, così che il processo di costruzione possa creare rappresentazioni diverse.

Il design pattern Builder è un pattern creazionale che viene utilizzato per creare oggetti complessi step by step. Il suo obiettivo principale è quello di separare la costruzione di un oggetto complesso dalla sua rappresentazione, in modo che lo stesso processo di costruzione possa essere utilizzato per creare oggetti differenti.

Il pattern Builder prevede l’utilizzo dei seguenti elementi:

• Oggetto Builder che viene utilizzato per definire le caratteristiche generali e comuni di oggetti omogenei.
• Metodi di “costruzione” che permettono di definire nello specifico l’oggetto finale passo dopo passo.

Scenari di utilizzo

Il pattern Builder può essere utilizzato ovunque ci sia la necessità di creare oggetti complessi in modo flessibile e modulare, e dove i passaggi di costruzione possono essere suddivisi in metodi più piccoli e gestibili.

Esempi concreti di impiego possono essere:

• Creazione di oggetti Model: Il pattern Builder può essere utilizzato per creare oggetti Model complessi passo dopo passo. Ad esempio, se si vuole creare un oggetto Model che rappresenta un Ordine con molti dettagli, il pattern Builder può semplificare il processo di creazione dell’oggetto suddividendo i passaggi in metodi più piccoli e gestibili.
• Costruzione di Query: Il pattern Builder può essere utilizzato per costruire query SQL complesse in modo flessibile e modulare.
• Creazione di oggetti View: Il pattern Builder può essere utilizzato per creare oggetti View complessi passo dopo passo.

Esempio di pattern Builder in PHP

Vediamo ora un esempio di codice in PHP che utilizza il pattern Builder per creare una classe che funga da query builder SQL.

class QueryBuilder {
  private $table;
  private $fields = array();
  private $conditions = array();

  public function table($table) {
    $this->table = $table;
    return $this;
  }

  public function select($fields) {
    $this->fields = $fields;
    return $this;
  }

  public function where($field, $operator, $value) {
    $this->conditions[] = array(
      'field' => $field,
      'operator' => $operator,
      'value' => $value
    );
    return $this;
  }

  public function build() {
    $query = 'SELECT ' . implode(', ', $this->fields) . ' FROM ' . $this->table;
    if (!empty($this->conditions)) {
      $query .= ' WHERE ';
      foreach ($this->conditions as $condition) {
        $query .= $condition['field'] . ' ' . $condition['operator'] . ' ' . $condition['value'] . ' AND ';
      }
      $query = rtrim($query, ' AND ');
    }
    return $query;
  }
}

In questo esempio, la classe QueryBuilder definisce i metodi per creare una query SQL complessa passo dopo passo. Il metodo table imposta la tabella su cui effettuare la query, il metodo select imposta i campi da selezionare, e il metodo where aggiunge una condizione alla clausola WHERE della query. Infine, il metodo build restituisce la query SQL completa.

Vediamo ora come utilizzare il query builder appena creato:

$query = (new QueryBuilder())
          ->table('products')
          ->select(array('id', 'name', 'price'))
          ->where('price', '>', 10)
          ->where('category', '=', 'electronics')
          ->build();
echo $query;
// Output: SELECT id, name, price FROM products WHERE price > 10 AND category = 'electronics'

Nell’esempio di utilizzo, si crea un oggetto QueryBuilder e si chiamano i metodi necessari per costruire la query desiderata, ovvero selezionare l’id, il nome e il prezzo dei prodotti con un prezzo maggiore di 10 e appartenenti alla categoria ‘electronics’. Infine, si chiama il metodo build per ottenere la query SQL completa.

Vantaggi del design pattern builder

• Consente di creare oggetti complessi step by step, separando la costruzione dell’oggetto dalla sua rappresentazione e facilitando il processo di creazione.
• Permette di creare oggetti con diverse configurazioni, utilizzando gli stessi passaggi di costruzione.
• Consente di creare oggetti in modo più flessibile e modulare, aggiungendo o rimuovendo passaggi di costruzione a seconda delle necessità.
• Consente di migliorare la leggibilità del codice, in particolare quando si hanno molti parametri da passare al costruttore.

Svantaggi del design pattern builder

• Può aumentare la complessità del codice, in particolare se si hanno molti passaggi di costruzione da definire.
• Può richiedere l’implementazione di molte classi aggiuntive (interfacce e classi concrete).
• Può introdurre un costo aggiuntivo di tempo di esecuzione a causa dell’utilizzo di oggetti intermedi durante il processo di costruzione.

Conclusioni

Il pattern Builder è un pattern molto utile e flessibile per la creazione di oggetti complessi, ma deve essere utilizzato con cautela e valutando attentamente le specifiche esigenze del progetto.

Per un panoramica generale sui design pattern consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Builder in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Lo Strategy pattern definisce una famiglia di algoritmi, li incapsula e li rende interscambiabili tra di loro. Strategy permette di variare gli algoritmi indipendentemente dai client che li usano.

Il design pattern Strategy è utile quando si desidera selezionare l’algoritmo da utilizzare in fase di esecuzione ed è composto da tre elementi fondamentali:

• L’interfaccia o la classe astratta “Strategy”: definisce il contratto che deve essere implementato dalle classi che rappresentano le diverse strategie di algoritmo. L’interfaccia o la classe astratta può includere un o più metodi, che rappresentano le operazioni che l’algoritmo deve essere in grado di eseguire.
• Le classi concrete delle strategie: queste classi implementano l’interfaccia o la classe astratta “Strategy” e rappresentano le diverse implementazioni degli algoritmi.
• La classe “Context”: rappresenta il contesto in cui viene eseguito l’algoritmo e che utilizza una delle strategie disponibili per l’esecuzione. La classe “Context” deve accettare un’istanza di una delle classi concrete delle strategie attraverso il costruttore e/o un metodo setter.

Scenario di utilizzo

Il desgin pattern Strategy è utile in situazioni in cui è necessario avere la possibilità di cambiare il comportamento di un’operazione in modo flessibile e senza dover modificare il codice dell’operazione stessa.

Esempi concreti di impiego possono essere:

• Nel controller di un framework MVC, è possibile utilizzare il pattern Strategy per incapsulare la logica di business associata a un’azione specifica. Ad esempio, se un’azione richiede la validazione dei dati di input, è possibile utilizzare una classe di validazione Strategy per gestire questo compito in modo indipendente dalla logica di business principale.
• Nel modello di un framework MVC, è possibile utilizzare il pattern Strategy per gestire la connessione ai diversi database utilizzati dall’applicazione. In questo modo, è possibile rendere la scelta del database dinamica e intercambiabile a runtime.
• Nel template di un framework MVC, è possibile utilizzare il pattern Strategy per definire diverse strategie di rendering a seconda del tipo di visualizzazione richiesta. Ad esempio, è possibile utilizzare una classe di rendering HTML per le visualizzazioni web e una classe di rendering JSON per le API REST.

Esempio di pattern Strategy in PHP

Supponiamo di dover calcolare il prezzo di un prodotto in un negozio online, ma il prezzo può variare in base a diversi fattori, come il tipo di sconto, le imposte applicabili e le tariffe di spedizione.

Invece di creare un metodo per ogni combinazione possibile di fattori, possiamo utilizzare il design pattern Strategy per creare un insieme di algoritmi, o strategie, che possono essere scelti in fase di esecuzione in base ai fattori specifici.

Vediamo ora il codice di base per implementare questo pattern.

// Creazione dell'interfaccia della strategia
interface PricingStrategy {
    public function calculatePrice($product);
}

// Implementazione della prima strategia: nessuno sconto
class NoDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice();
    }
}

// Implementazione della seconda strategia: sconto del 10%
class TenPercentDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice() * 0.9;
    }
}

// Implementazione della terza strategia: sconto del 20%
class TwentyPercentDiscountStrategy implements PricingStrategy {
    public function calculatePrice($product) {
        return $product->getPrice() * 0.8;
    }
}

// Implementazione della classe prodotto
class Product {
    private $price;
    private $pricingStrategy;
    
    public function __construct($price, $pricingStrategy) {
        $this->price = $price;
        $this->pricingStrategy = $pricingStrategy;
    }
    
    public function getPrice() {
        return $this->pricingStrategy->calculatePrice($this);
    }
    
    public function setPricingStrategy($pricingStrategy) {
        $this->pricingStrategy = $pricingStrategy;
    }
}

// Utilizzo del codice
$product = new Product(100, new NoDiscountStrategy());
echo $product->getPrice(); // output: 100

$product->setPricingStrategy(new TenPercentDiscountStrategy());
echo $product->getPrice(); // output: 90

$product->setPricingStrategy(new TwentyPercentDiscountStrategy());
echo $product->getPrice(); // output: 80

In questo esempio, abbiamo creato un’interfaccia PricingStrategy che definisce un metodo calculatePrice(), che viene implementato dalle classi NoDiscountStrategy, TenPercentDiscountStrategy e TwentyPercentDiscountStrategy.

Abbiamo quindi creato una classe Product che accetta un oggetto PricingStrategy nel suo costruttore e ha un metodo getPrice() che utilizza la strategia selezionata per calcolare il prezzo del prodotto.

Infine, abbiamo creato un oggetto Product con un prezzo di 100 e senza sconto, e abbiamo utilizzato il metodo setPricingStrategy() per selezionare le altre strategie di sconto e calcolare il prezzo del prodotto in base ad esse.

Vantaggi del design pattern strategy

• Consente di isolare la logica di business in classi separate, rendendo il codice più modulare e facile da testare.
• Permette di sostituire gli algoritmi utilizzati in modo semplice e senza dover modificare il codice esistente.
• Favorisce l’estendibilità del codice, poiché nuovi algoritmi possono essere facilmente aggiunti senza dover modificare la struttura esistente.

Svantaggi del design pattern strategy

• L’uso del pattern Strategy può portare a un aumento della complessità del codice, poiché richiede la creazione di molte classi aggiuntive.
• Il pattern Strategy potrebbe non essere necessario in tutti i casi e potrebbe rappresentare una soluzione eccessiva in alcune situazioni.

Conclusioni

Il design pattern Strategy può essere una soluzione potente per creare codice modulare e flessibile, ma deve essere utilizzato con cautela e solo quando è effettivamente necessario.

Per un panoramica generale consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Strategy in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Il Singleton pattern assicura che una sola istanza di una classe esista, fornendo un punto di accesso globale a tale istanza.

Il pattern Singleton impedisce la creazione di più istanze di una classe garantendo che ne esista solo una e fornisce un modo per accedere a quell’istanza unica da qualsiasi parte dell’applicazione.

Il singleton prevede tre elementi fondamentali:

• Costruttore privato: impedisce la creazione di istanze della classe dal di fuori della classe stessa.
• Variabile statica privata: mantiene l’istanza unica della classe. Deve essere privata per evitare che altri oggetti accedano ad essa direttamente.
• Metodo statico di accesso all’istanza: restituisce l’istanza unica della classe. Se l’istanza non esiste ancora, il metodo crea l’istanza e la restituisce, altrimenti restituisce semplicemente l’istanza esistente.

Scenari di utilizzo

Il pattern singleton può essere utilizzato quando un certo oggetto deve essere “unico” all’interno del nostro applicativo, per un ruolo di coordinamento o per ottimizzare le risorse. Ecco alcuni esempi concreti di utilizzo:

• Registro / Storage condiviso
• Log / Debug
• Connessione a DB persistente

Esempio di pattern Singleton in PHP

Vediamo ora il codice di base per implementare questo pattern.

class MySingleton {

    /**
     * Istanza unica del singleton
     * @var object
     */
    private static object $instance;

    /**
     * Costruttore privato per prevenire che venga istanziato da codice esterno.
     */
    private function __construct() {
        echo 'Faccio qualcosa...';
    }

    /**
     * Metodo pubblico per l'accesso all'istanza unica di classe.
     * @return object|MySingleton
     */
    public static function getInstance() {
        if ( !isset(self::$instance) ) {
            self::$instance = new MySingleton();
        }
        return self::$instance;
    }
}

Se proviamo ad istanziare due volte il singleton noteremo che il messaggio “Faccio qualcosa…” presente nel costruttore verrà mostrato una sola volta. poiché il sistema utilizzato per implementarlo garantisce l’unicità dell’istanza (oggetto).

Per rendere il codice più riutilizzabile possiamo apportare una piccola modifica all’interno del metodo getIstance() in modo che il nome della classe istanziata con new sia valorizzato automaticamente. Sfruttiamo la costante magica __CLASS__ che restituisce il nome della classe nella quale è richiamata.

if ( !isset(self::$instance) ) {
    $className = __CLASS__;
    self::$instance = new $className;
}

Vantaggi del design pattern singleton

• Garantisce una sola istanza: Il pattern Singleton garantisce che una sola istanza di una classe esista in un determinato momento, il che può essere utile in alcune situazioni, ad esempio per gestire le connessioni al database o le impostazioni globali dell’applicazione.
• Facile accesso globale: Il pattern Singleton fornisce un punto di accesso globale all’istanza unica, il che significa che possiamo accedere all’istanza ovunque e in qualsiasi momento senza dover preoccuparci di passare l’istanza esplicitamente a ogni parte dell’applicazione.
• Riduzione del consumo di memoria: Poiché una sola istanza esiste in un determinato momento, il pattern Singleton può aiutare a ridurre il consumo di memoria del sistema.

Svantaggi del design pattern singleton

Alcuni puristi della programmazione ad oggetti (OOP) possono storcere il naso quando si parla di singleton definendolo un anti-pattern. Le principali critiche al singleton sono le seguenti:

• Viola il Single Responsibility Principle (SRP) se crea delle dipendenze nei componenti che lo utilizzano. L’SRP vorrebbe infatti ogni componente assegnato ad una singola funzione o responsabilità.
• Difficile da testare poiché l’istanza unica esiste in tutta l’applicazione e non può essere facilmente sostituita con una mock o una versione di prova.
• Difficile da estendere poiché impone l’esistenza di una sola istanza di una classe in un determinato momento, può essere difficile estendere il pattern se si desidera introdurre più istanze della classe.
• Crea accoppiamento forte: poiché ogni parte dell’applicazione che utilizza il Singleton dipende dal suo stato globale.
• Viene utilizzato erroneamente per sostituire le variabili globali che, per definizione, non devono essere influenzate dall’applicativo.

Conclusioni

Il singleton si può rivelare molto utile in specifiche situazioni, ma non bisogna abusarne così come non bisogna abusare delle implementazioni statiche nella programmazione ad oggetti. Può essere utile valutare anche altri tipi di soluzioni come la Dependency Injectiono il pattern Factory.

Per un panoramica generale consiglio di leggere l’articolo introduttivo sui design patterns.

L'articolo Design Pattern Singleton in Php sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Progettare software ad oggetti è difficile, ma lo è ancora di più renderne i suoi componenti riutilizzabili. La scomposizione dell’applicativo in oggetti deve tener conto di molteplici fattori: incapsulamento, granularità, dipendenza, performance, ridondanza, riusabilità, modularità, estendibilità nel tempo.

I design pattern vengono in nostro soccorso indicandoci soluzioni a problemi ricorrenti così da rendere il nostro codice riutilizzabile e mantenibile.

La genesi

Il concetto di design pattern è stato mutuato dall’ingegneria del software direttamente dall’architettura. Fu l’architetto austriaco Cristopher Alexander a formalizzare tale concetto nel 1977 all’interno del libro Pattern Language: Towns, Buildings, Construction.

Il pattern è una soluzione architetturale che può risolvere problemi in contesti eterogenei.

La trasposizione del concetto di design pattern in ambito informatico è attribuita invece alla cosiddetta Gang of Four (GoF) formata da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Dopo quatro anni di confronto condensarono tutta la loro esperienza in un libro del 1994 che è diventato la “Bibbia della programmazione ad oggetti”: Design Patterns: elements of reusable object oriented software“ (Elementi per il riuso di software ad oggetti).

Il design pattern descrive un problema ricorrente e fornisce una soluzione che può essere riutilizzata infinite volte senza doverla applicare mai nello stesso identico modo

Design Pattern: classificazione

La GoF cataloga i suoi 23 pattern suddividendoli in 3 macro categorie:

• Pattern creazionali: soluzioni per creare oggetti.
• Pattern strutturali: soluzioni per la composizione strutturale di classi e oggetti.
• Pattern comportamentali: soluzioni per gestire le responsabilità delle classi e degli oggetti.

Una seconda classificazione viene fatta in base al loro ambito applicativo:

• Class pattern: soluzioni tramite classi e sottoclassi in relazioni statiche tra loro.
• Object Pattern: soluzioni dinamiche basate sugli oggetti.

Infine ogni pattern viene descritto in base agli elementi che lo caratterizzano:

• Nome/Alias: sintentizza l’essenza del pattern.
• Scopo: cosa fa il pattern.
• Motivazione: scenario del problema e soluzione offerta.
• Applicabilità: situazioni di esempio in cui si può usare il pattern.
• Struttura: rappresentazione grafica delle classi del pattern.
• Partecipanti: classi/oggetti interessati e relative responsabilità
• Collaborazioni: dei partecipanti per poter assumersi le responsabilità.
• Conseguenze: pro e contro del pattern.
• Implementazione: tecniche e consigli per implementare il pattern.
• Codice d’esempio: in C++ e SmallTalk.
• Utilizzi noti: esempi reali in sistemi esistenti.
• Correlazioni: legami con altri pattern e differenze.

I 23 pattern definiti dal GoF possono essere quindi così schematizzati:

Design Pattern: il catalogo della GoF

Riporto qui una sintesi del catalogo composto dai 23 design pattern in modo da avere un’idea di massima del loro utilizzo.
Ricordo che con il termine “interfaccia” si intende qui l’insieme delle richieste a cui un oggetto può rispondere cioè l’insieme delle proprietà e dei metodi pubblici di un oggetto. Attenzione quindi a non confondersi con le “interface” di Php!

• Abstract Factory: fornisce un’interfaccia per la creazione di famiglie di oggetti correlati o dipendenti senza specificare o conoscere le classi concrete.
• Adapter: converte l’interfaccia di una classe in un’altra interfaccia richiesta dal client permettendo la collaborazione fra classi tra loro incompatibili.
• Bridge: disaccoppia un’astrazione dalla sua implementazione in modo che le due possano variare indipendentemente.
• Builder: separa la costruzione di un oggetto complesso dalla sua rappresentazione così che lo stesso processo di creazione possa creare rappresentazioni diverse.
• Chain of Responsability: disaccoppia il mittente di una richiesta dal suo destinatario. Si ordinano gli oggetti destinatari e la richiesta viene passata di oggetto in oggetto finché non viene gestita.
• Command: incapsula una richiesta in un oggetto.
• Composite: raggruppa oggetti in strutture ad albero permettendo ai client di trattare oggetti singoli e raggruppamenti in modo uniforme.
• Decorator: aggiunge dinamicamente responsabilità ad un oggetto. E’ un’aternativa flessibile all’ereditarietà.
• Facade: definisce un’interfaccia di più alto livello per facilitare l’utilizzo di un sottosistema più complesso.
• Factory Method: permette ad una classe di delegare la creazione di un oggetto alle sue sottoclassi.
• Flyweight: usa la condivisione per gestire numerosi oggetti a granularità fine.
• Interpreter: permette di implementare un proprio linguaggio con la sua grammatica ed il relativo interprete.
• Iterator: permette di accedere agli elementi di un contenitore sequenzialmente senza esporre la struttura sottostante.
• Mediator: favorisce un basso accoppiamento evitando che gli oggetti facciano riferimento l’un l’altro.
• Memento: esplicita lo stato interno di un oggetto così da poterlo riportare al suo stato originale.
• Observer: definisce una dipendenza uno-a-molti fra oggetti così che quando un oggetto cambia stato tutti gli oggetti dipendenti vengano notificati ed aggiornati.
• Prototype: specifica gli oggetti da creare utilizzando un’istanza prototipale.
• Proxy: fornisce un surrogato di un oggetto pper controllare l’accesso a quest’ultimo.
• Singleton: forza una classe ad avere una sola istanza e ne fornisce un accesso globale.
• State: permette ad un oggetto di modificare il proprio comportamento quando il suo stato interno cambia. Sembrerà che l’oggetto abbia cambiato la sua classe.
• Strategy: definisce una famiglia di algoritmi, li incapsula e li rende interscambiabili tra di loro.
• Template Method: definisce lo scheletro principale dell’algoritmo in un metodo delegando alcuni passi alle sottoclassi.
• Visitor: permette di definire nuove operazioni senza cambiare le classi degli elementi su cui opera.

Riferimenti

Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Pearson Education

https://designpatternsphp.readthedocs.io

https://refactoring.guru/design-patterns

L'articolo Design Pattern GoF – Guida sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Cosa sono i namespaces in php?

What are namespaces? In the broadest definition namespaces are a way of encapsulating items.

I namespaces, introdotti in PHP 5.3 e migliorati in PHP 7, permettono di raggruppare classi, interfacce, funzioni e costanti per evitare ambiguità di denominazione. In questo modo potremo far coesistere classi con lo stesso nome “incapsulate” in namespace differenti esattamente come avviene per file con lo stesso nome posti in cartelle diverse del filesystem. La possibilità di creare una gerarchizzazione (sub-namespace) fornisce una chiara indicazione sull’organizzazione delle risorse del nostro applicativo. Ad esempio, assegnando i namespaces Framework\Core\Main ad un file contenente una classe e Framework\Core\Main\Libs ad un altro contenente un’altra classe con il medesimo nome, è facilmente intuibile come la prima si riferisca alle funzionalità di base del nostro ipotetico framework e l’altra sia presente in una libreria secondaria.

Pur essendo forte l’analaogia con il filesystem non sussite alcuna relazione diretta fra un namespace ed il percorso dei file .php. E’ però intuitivo utilizzare questa analogia per creare vincoli convenzionali e sfruttarli nella pratica dell’autoloading la cui implementazione più diffusa è sintetizzata nello standard PSR-4 che approfondirò in un altro articolo.

Namespaces: vantaggi di utilizzo

• Risolvono il problema di omonimia di classi, interfacce, funzioni e costanti tra il codice scritto dallo sviluppatore, quello integrato in librerire di terze parti e quello nativo di Php.
• Facilitano lo sviluppo di codice ordinato, organizzato ed “eloquente”.
• Migliorano la leggibilità e la scrittura del codice permettendo di utilizzare degli alias nel momento in cui la precisa ed inevitabile lunghezza del namespace non fosse necessaria.

Namespaces: dichiarazione

Compresi i vantaggi del loro utilizzo vediamo come utilizzare i namespaces iniziando dalla loro dichiarazione attraverso l’apposita keyword <strong>namespace</strong>.
Uno script che faccia uso di namespaces deve dichiararlo all’inizio del listato fatta eccezione per i commenti ed eventuali istruzioni declare.

<?php
declare(encoding='UTF-8');

// Dichiaro il namespace...
namespace Framework\Core\Main;

Attenzione!

• I namespaces non possono contenere keywords del linguaggio php.
  Framework\Core\<s>Class</s>
• I namespaces non possono iniziare con un numero.
  Framework\Core\<s>1Class</s>
• E’ possibile, ma altamente sconsigliato, dichiarare più namespaces nello stesso file utilizzando le parentesi graffe.
  <?php<br /><em><strong>Framework\Core\Main</strong></em> { // codice }<br /><em><strong>Framework\Core\Libs</strong></em> { // codice }

Php Namespaces: dalla teoria alla pratica

Immaginiamo di creare ed includere due file php contenenti la dichiarazione di una classe denominata nello stesso modo (Es: MyClass). Una volta in esecuzione otterremmo questo errore:
<strong>Fatal error</strong>: Cannot declare class MyClass, because the name is already in use

Aggiungiamo ora ai due file una dichiarazione namespace…

<?php // File 1: /Framework/Core/Main/MyClass.php

namespace Framework\Core\Main;

Class MyClass {
    public function __construct() {
        echo '<p>MAIN: MyClass ready!</p>';
    }
}

<?php // File 2: /Framework/Core/Main/Libs/MyClass.php

namespace Framework\Core\Main\Libs;

Class MyClass {
    public function __construct() {
        echo '<p>LIBS: MyClass ready!</p>';
    }
}

Creiamo ora il file principale ex01.php che li includerà e tenterà di creare un oggetto.

<?php // File: /ex01.php

// Includo i file
require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// Creo l'oggetto
$objOne = New MyClass();

Mandandolo in esecuzione ci troveremo davanti ancora un errore…
<strong>Fatal error</strong>: Uncaught Error: Class 'MyClass' not found in...

Questo si verifica poichè le nostre due classi “MyClass” sono assegnate ai rispettivi namespaces, mentre il nostro file principale non ha alcun namespace specificato e si riferisce quindi a quello globale in cui la classe MyClass() non è definita.

Namespaces: tipi di riferimento

Sappiamo definire i namespaces, ma per richiamarli correttamente dobbiamo conoscere quali sono i tipi di riferimento che possiamo utilizzare e che nuovamente hanno una forte analogia con i percorsi dei filesystem:

• Unqualified name (nomi non qualificati): si riferiscono solo al namespace corrente. È come cercare un fille nella cartella in cui ci si trova.
  MyClass()
• Qualified name (nomi qualificati): paragonabile al percorso relativo di un file.
  Main\Libs\MyClass()
• Fully-qualified name (nomi completamente qualificati): inizia sempre con un backslash iniziale ed è paragonabile ad un percorso assoluto. È il modo più sicuro anche se più verboso.
  \Framework\Core\Main\Libs\MyClass()

Unqualified name – Nel file principale (ex02.php) dichiariamo lo stesso namespace di uno dei due file contenenti la dichiarazione di MyClass() che vorremmo richiare, ad esempio Libs: Framework\Core\Main\Libs. Ecco finalmente il primo risultato positivo!

<?php // File: /ex02.php

// Dichiaro il namespace
namespace Framework\Core\Main\Libs;

// Includo i file
require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// UNQUALIFIED NAME...
$objOne = New MyClass();

Qualified name – Nel file principale (ex03.php) dichiariamo un namespace più generico Framework\Core ed utilizzamo nomi qualificati per riferirci ad entrambe le nostre classi ed ottenere i relativi oggetti.

<?php
// File: /ex03.php

// Dichiaro il namespace
namespace Framework\Core;

require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// QUALIFIED NAME...
$objOneMain = New Main\MyClass();
$objOneLib = New Main\Libs\MyClass();

Nota: una volta dichiarato un namespace, per riferirsi al contesto globale è necessario anteporre il backslash.

Fully-qualified name – Nel file principale (ex04.php) omettiamo il namespace, ma utilizziamo un nome completamente qualificato per riferirci alle due classi.

<?php // File: /ex04.php

// Includo i file
require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// FULLY-QUALIFIED NAME...
$objOneMain = New \Framework\Core\Main\MyClass();
$objOneLib = New \Framework\Core\Main\Libs\MyClass();

Php Namespaces: importazione e aliasing tramite l’operatore “use”

Una caratteristica importante dei namespaces è la possibilità di essere importati e di creare degli alias per renderne più pratico l’utilizzo vista la loro “eloquenza”. Queste funzioni trovano un parallelismo nella capictà dei filesystem di creare link simbolici a file o cartelle.
A tale scopo Php mette a disposizione la keyword <strong>use</strong> con la quale è possibile eseguire i seguenti tipi di seguenti tipi di importazione/aliasing:

• nomi di classi o interfacce (use Name\Space\ClassName),
• nomi di classi o interfacce globali (use DateTime)
• namespaces (use Name\Space\For\...)
• nomi di funzioni (use function Name\Space\FunctionName)
• nomi di costanti (use const Name\Space\CONSTANT).

E’ possibile importare anche più elementi nello stesso file purché non si generino delle ambiguità, in tal caso si potrà ricorrere agli alias.

Applichiamo use al nostro scenario di esempio (ex05.php) per importare i namespaces comuni alla due classi e sintetizzarli in “Main”.

<?php // File: /ex05.php

use Framework\Core\Main as Main;

// Includo i file
require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// QUALIFIED NAME...
$objOneMain = New Main\MyClass();
$objOneLib = New Main\Libs\MyClass();

Nell’esempio seguente (ex06.php) utilizziamo use per superare l’ambiguita dei nomi delle classi e creare un alias dei namespaces.

<?php // File: /ex06.php

use Framework\Core\Main\MyClass as MainMy;
use Framework\Core\Main\Libs\MyClass as LibsMy;

// Includo i file
require_once('Framework/Core/Main/MyClass.php');
require_once('Framework/Core/Main/Libs/MyClass.php');

// UNQUALIFIED NAME...
$objOneMain = New MainMy();
$objOneLib = New LibsMy();

Direi sia tutto! Qui trovate i file di esempio visti nella lezione e se l’articolo è stato utile… condividilo!

L'articolo Php Namespaces sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.