Written by 21:58 DEVeloperS, Principi SOLID

Introduzione ai principi SOLID

david michelangelo

SOLID è un acronimo coniato da Michael Feathers che aiuta a ricordare cinque principi di design descritti nei primi anni 2000 dallo zio d’America Uncle Bob, al secolo Robert C. Martin.
Lo scopo di questi principi è quella di formulare delle linee guida per arrivare ad un design che produca codice più comprensibile, flessibile e manutenibile.
Per quanto riguarda l’ambito di applicazione, sebbene in object-oriented sia possibile adoperarli in generale, essi trovano terreno fertile in contesti di sviluppo agili, fondati sull’identificazione di code smell e sul refactoring.

SRPSingle ResponsibilityA class should have one, and only one, reason to change.
OCPOpen CloseYou should be able to extend a classes behavior, without modifying it.
LSPLiskov SubstitutionDerived classes must be substitutable for their base classes.
ISPInterface SegregationMake fine grained interfaces that are client specific.
DIPDependency InversionDepend on abstractions, not on concretions.
SOLID principles

Qualche premessa…

The SOLID principles are not rules.
They are not laws.
They are not perfect truths.
The are statements on the order of “An apple a day keeps the doctor away.”

Uncle Bob

Una premessa importante da fare è che la nostra amata computer science non è una scienza esatta e molto spesso segue leggi empiriche dettate dell’esperienza.
Questo vale anche per i principi SOLID che, quindi, devono essere inquadrati come soluzioni di buon senso a problemi comuni, un po’ come i design pattern. In parole povere, non c’è alcuna dimostrazione inoppugnabile che accerti che i principi possano essere sempre efficaci: sono la panacea a tanti mali, ma occorre contestualizzarli ed applicarli solo laddove necessario.

Viceversa, la seconda premessa, in controtendenza con la prima, è: se non sapete cosa fare, usateli quanto prima! Se non sapete rispondere a domande quali:
Cos’è il design object-oriented?
Quali sono i costi ed i benefici che ha apportato?
Oppure, se semplicemente siete agli inizi della vostra carriera ed entrate a piè pari in un progetto enterprise, allora non c’è molto su cui riflettere. In futuro, quando avrete accumulato maggiore esperienza, si affinerà anche la sensibilità per ponderare una scelta più ragionata.
Sembrerà strano, ma la stragrande maggioranza dei software developer di oggi usa un linguaggio object oriented di qualche sorta e lo fa senza sapere il perché e come trarne massimo giovamento. In questi casi sarebbe bene ritornare alle basi, magari leggendo un buon libro sull’OO programming. Tuttavia, se i sempre più striminziti tempi che riusciamo a dedicare a noi stessi non ce lo consentono, partiamo con l’usare sistematicamente il single responsibility principle. Infatti, l’SRP è il nodo di partenza di tutti gli altri.

Few people realize that the single responsibility principle and the open closed principle are the same thing.

Michael Feathers

What we talk about when we talk about design

Occorre ora fare una leggera virata dall’argomento principale per parlare di architettura e design.

Nonostante non sia completamente corretto, spesso si utilizzano in maniera intercambiabile le parole “architettura” e “design“. Tuttavia, nella realtà dei fatti l’architettura software è il risultato finale del processo di design (progettazione).

Dunque, di cosa parliamo quando parliamo di architettura? La risposta, per fare una battuta, è multitiered.

Usando una definizione che deriva dallo standard IEEE 1471-2000, l’architettura software è l’organizzazione fondamentale di un sistema, definita dai suoi componenti, dalle relazioni reciproche tra i componenti e con l’ambiente, e i principi che ne governano la progettazione e
l’evoluzione.

Il design può descrivere il funzionamento interno di un sistema a diversi livelli di dettaglio.
A livello più alto, ci sono i pattern architetturali che delineano i contorni generali e la struttura delle applicazioni software. Certamente avrete sentito parlare di architetture come client-server o multitiered. Queste sono formule che identificano solo la struttura del sistema nel suo complesso, definendo i principali moduli e le loro relazioni macroscopiche.
Scendendo di qualche livello abbiamo, invece, l’architettura dei moduli/componenti software e delle loro interconnessioni. Per intenderci, questo è il dominio dei design pattern, dei packages, delle componenti e delle classi. Ed è anche il livello di nostro interesse in questo articolo, perché è a questo livello che agiscono i principi SOLID come elementi di design che fungono da firewall contro il degrado architetturale.

(Visited 36 times, 1 visits today)

Close