SOLID

Matteo 5 min

Nello sviluppo software, uno degli obiettivi principali è quello di scrivere codice mantenibile, flessibile e facile da testare. Un insieme di linee guida per raggiungere questi obiettivi sono i princìpi SOLID, che aiutano gli sviluppatori a creare software più robusto e scalabile.

Questi princìpi furono enunciati da Robert C. Martin, meglio conosciuto come Uncle Bob, e sono diventati dei pilastri per lo sviluppo di codice orientato agli oggetti.

Cos’è SOLID?

SOLID è un acronimo, ed ogni lettera rappresenta un principio:

  • S: Single Responsibility Principle (Principio di Responsabilità Singola)
  • O: Open/Closed Principle (Principio Aperto/Chiuso)
  • L: Liskov Substitution Principle (Principio di Sostituzione di Liskov)
  • I: Interface Segregation Principle (Principio di Segregazione delle Interfacce)
  • D: Dependency Inversion Principle (Principio di Inversione delle Dipendenze)

Single Responsibility Principle (SRP)

Una classe dovrebbe avere una, e una sola, ragione per cambiare. Il SRP afferma che ogni classe deve essere responsabile di una sola cosa. Questo principio rende il codice più comprensibile, riduce l’accoppiamento e aumenta la coesione. Quando una classe ha più di una responsabilità, diventa più difficile modificarla o aggiornarla senza rompere il suo comportamento.

Esempio:

Una classe che gestisce sia la logica di business che l’accesso ai dati viola il principio SRP. È preferibile separare la logica in una classe dedicata (ad esempio, un service) e l’accesso ai dati in un’altra (ad esempio, un repository).

// Esempio di classe che viola SRP
class UserManager {
    public function saveUser($user) {
        // logica di business
        // ...
        
        // accesso ai dati
        Database::save($user);
    }
}

// Implementazione corretta
class UserService {
    private $userRepository;
    
    public function __construct(UserRepository $userRepository) {
        $this->userRepository = $userRepository;
    }
    
    public function saveUser($user) {
        // logica di business
        // ...
        
        $this->userRepository->save($user);
    }
}

Open/Closed Principle (OCP)

Le entità software (classi, moduli, funzioni, ecc.) dovrebbero essere aperte all’estensione, ma chiuse alla modifica. Questo principio suggerisce che le classi dovrebbero essere progettate in modo tale che il loro comportamento possa essere esteso senza modificarne il codice esistente. Questo si ottiene tramite ereditarietà o composizione, rendendo il codice più flessibile e meno soggetto a bug.

Esempio:

Se abbiamo una classe che calcola sconti per un cliente, possiamo estendere la funzionalità aggiungendo nuove classi senza toccare la logica esistente.

// Implementazione violata
class DiscountManager {
    public function applyDiscount($amount) {
        return $amount * 0.9; // 10% di sconto fisso
    }
}

// Implementazione corretta
interface Discount {
    public function apply($amount);
}

class PercentageDiscount implements Discount {
    public function apply($amount) {
        return $amount * 0.9;
    }
}

class FixedDiscount implements Discount {
    public function apply($amount) {
        return $amount - 10;
    }
}

class DiscountManager {
    private $discount;
    
    public function __construct(Discount $discount) {
        $this->discount = $discount;
    }
    
    public function applyDiscount($amount) {
        return $this->discount->apply($amount);
    }
}

Liskov Substitution Principle (LSP)

Gli oggetti dovrebbero poter essere sostituiti con le loro sottoclassi senza alterare la correttezza del programma. Il principio di sostituzione di Liskov, formulato da Barbara Liskov, afferma che una sottoclasse deve poter sostituire la sua classe base senza che il comportamento del programma venga alterato. Ciò significa che le sottoclassi non dovrebbero violare le aspettative stabilite dalle classi base.

Esempio:

Se una classe Square eredita da Rectangle, dovrebbe mantenere il comportamento di base di un rettangolo. Altrimenti, stiamo violando il principio di Liskov.

// Esempio che viola LSP
class Rectangle {
    protected $width;
    protected $height;

    public function setWidth($width) {
        $this->width = $width;
    }

    public function setHeight($height) {
        $this->height = $height;
    }

    public function getArea() {
        return $this->width * $this->height;
    }
}

class Square extends Rectangle {
    public function setWidth($width) {
        $this->width = $width;
        $this->height = $width;
    }

    public function setHeight($height) {
        $this->width = $height;
        $this->height = $height;
    }
}

In questo caso, Square non rispetta il comportamento di base del rettangolo, violando il principio LSP.

Interface Segregation Principle (ISP)

I client non dovrebbero essere costretti a dipendere da interfacce che non usano. Il principio di segregazione delle interfacce afferma che è meglio avere più interfacce specifiche per un tipo di funzionalità, piuttosto che una singola interfaccia grande che racchiude troppe responsabilità. Ciò consente ai client di dipendere solo dalle funzionalità di cui hanno bisogno.

Esempio:

Se abbiamo un’interfaccia Animal che definisce fly(), swim() e walk(), obblighiamo tutti gli animali a implementare metodi che non hanno senso per tutti.

// Violazione ISP
interface Animal {
    public function fly();
    public function swim();
    public function walk();
}

// Corretta segregazione delle interfacce
interface CanFly {
    public function fly();
}

interface CanSwim {
    public function swim();
}

interface CanWalk {
    public function walk();
}

Dependency Inversion Principle (DIP)

Le dipendenze dovrebbero dipendere da astrazioni e non da concreti. Il principio di inversione delle dipendenze afferma che le classi non dovrebbero dipendere da altre classi concrete, ma da astrazioni (come interfacce o classi astratte). Questo rende il codice più flessibile e facile da testare, perché le dipendenze possono essere facilmente sostituite o mockate.

Esempio:

// Violazione DIP
class EmailService {
    public function sendEmail($message) {
        // invio email
    }
}

class Notification {
    private $emailService;
    
    public function __construct() {
        $this->emailService = new EmailService();
    }
    
    public function notify($message) {
        $this->emailService->sendEmail($message);
    }
}

// Corretto uso del DIP
interface MessageService {
    public function sendMessage($message);
}

class EmailService implements MessageService {
    public function sendMessage($message) {
        // invio email
    }
}

class Notification {
    private $messageService;
    
    public function __construct(MessageService $messageService) {
        $this->messageService = $messageService;
    }
    
    public function notify($message) {
        $this->messageService->sendMessage($message);
    }
}

Conclusione

I principi SOLID sono fondamentali per lo sviluppo di software di qualità. Applicandoli correttamente, è possibile ottenere un codice che sia più facile da mantenere, testare ed estendere. La loro adozione non solo migliora la qualità del software, ma riduce anche i costi di manutenzione a lungo termine. La comprensione e l’implementazione dei principi SOLID è un passo essenziale per qualsiasi sviluppatore orientato alla costruzione di soluzioni software eleganti ed efficienti.

content_copy Copiato