SOLID, i principi fondamentali del design Object-Oriented

_Logo SOLID è un acronimo introdotto da Michael Feathers per indicare i primi cinque e fondamentali principi indentificati da Robert C. Martin nell'ambito del design di applicativi Object Oriented. L'obiettivo è come sempre è semplificare la manutenzione, la testabilità e l'estendibilità.

Principi che non solo evitano il cosiddetto code smell ma aiutano a identificarlo in caso di refactoring. Fanno parte integrante della più ampia strategia della programmazione agile e adattiva.

Tali principi sono stati esposti in modo completo da Uncle Bob in uno dei testi fondamentali dedicati allo sviluppo software: Clean Code. Rappresentano delle linee guida e sono un requisito fondamentale per ogni sviluppatore, ancor più di un qualsiasi pattern e conoscenza specifica di una determinata tecnologia. Riconoscere ed applicare tali principi semplifica tutte le fasi della vita dell'applicativo.

Di seguito una rapida panoramica dei cinque principi con il collegamento agli articoli più dettagliati:

  • SRP, Single responsibility principle: una classe deve avere una sola responsabilità. Originalmente formalizzando indicando che deve avere un unico motivo per cambiare. Il concetto è stato esteso anche agli altri elementi di una applicazione: progetti, classi e metodi.
    “THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.”
  • OCP, Open/closed principle: gli elementi dell'applicazione devono essere aperte all'estensione e chiusi alle modifiche.
    “SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.”
  • LSP, Liskov substitution principle: gli oggetti dovrebbero poter essere sostituiti con dei loro sottotipi, senza alterare il comportamento del programma che li utilizza.
    “FUNCTIONS THAT USE ... REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.”
  • ISP, Interface segregation principle: sarebbero preferibili più interfacce specifiche, che una singola interfaccia generica.
    “CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE”
  • DIP, Dependency inversion principle: una classe dovrebbe dipendere dalle astrazioni, non da classi concrete.
    “A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS
    B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS”

A questi principi si legano i seguenti argomenti:

Tag: SOLID