I principi SOLID

Transcript

1. I principi SOLID Alessandro Desantis
2. Principio di singola responsabilità Ogni contesto deve avere una sola responsabilità e incapsularla completamente. Tutti i suoi servizi devono essere strettamente allineati con tale responsabilità.
3. Principio di singola responsabilità Ciascun contesto dovrebbe cambiare solo per una singola causa (responsabilità). Ogni nuova responsabilità è una nuova potenziale causa di cambiamento. Un cambiamento può danneggiare o inficiare le altre responsabilità.
4. Principio di singola responsabilità Le responsabilità multiple: 1) consumano più memoria del necessario; 2) rallentano il processo di compilazione; 3) complicano il processo di linking; 4) allungano il codice.
5. Principio aperto/chiuso Le entità devono essere aperte all’ estensione... ma chiuse alla modifica.
6. class Shape { public: int width; int height; }; Principio aperto/chiuso Ereditarità dell’implementazione class Rectangle: public Shape { public: int getArea() { return (width * height); } }; Classe base (o superclasse) Estensione Estensione
7. Principio aperto/chiuso Ereditarità dell’interfaccia Classe astratta (o interfaccia) Implementazione Implementazione Classe astratta (o interfaccia) Implementazione Implementazione class Shape { public: int width; int height; virtual int getArea() = 0; }; class Rectangle: public Shape { public: int getArea() { return (width * height); } };
8. Principio di sostituzione di Liskov Se S è un sottotipo di T, allora gli oggetti di tipo T possono essere sostituiti con oggetti di tipo S senza alterare le caratteristiche del programma.
9. class Person { public: void walk(int steps) { // ... } }; class Prisoner: public Person { public: void walk(int steps) { // Un prigioniero non può camminare! } }; Principio di sostituzione di Liskov
10. class Person { }; class Prisoner: public Person { }; Principio di sostituzione di Liskov class FreePerson: public Person { public: void walk(int steps) { // ... } };
11. Principio di segregazione delle interfacce Nessun client dovrebbe essere obbligato a dipendere da interfacce che non usa.
12. class IWorker { virtual void work() = 0; virtual void eat() = 0; }; class Worker: public IWorker { void work() { // ... } void eat() { // ... } }; Principio di segregazione delle interfacce class Manager { void manage(IWorker *w) { worker->work(); } }; Manager non usa il metodo eat() di IWorker.
13. Le interfacce dovrebbero: contenere pochi e semplici metodi; avere un ruolo definito. Principio di segregazione delle interfacce Così che i client possano: usare tutti i metodi di un’interfaccia.
14. Principio di inversione delle dipendenze I moduli di alto livello non devono dipendere da quelli di basso livello. Entrambi devono dipendere da astrazioni. Le astrazioni non devono dipendere dai dettagli; sono i dettagli che dipendono dalle astrazioni.
15. Principio di inversione delle dipendenze class Car { // ... } class Driver { public: void drive(Car *car) { // ... } } Il metodo drive di Driver dipende dalla classe Car.
16. Principio di inversione delle dipendenze class ICar { // ... } class Car: public ICar { // ... } class Driver { public: void drive(ICar *car) { // ... } } Il metodo drive di Driver dipende dall’astrazione ICar.
17. Grazie!