SOLID Principi demistificati — Intro

Costruire software complesso è allo stesso tempo esaltante e stimolante, ma è ancora più impegnativo e deprimente quando si mantiene e si aggiorna un software scritto male.

La metodologia in cui scriviamo codice grande e ben strutturato è seguendo e aderendo a una serie di principi chiamati Principi SOLID .

I principi SOLID sono stati introdotti per la prima volta dallo scienziato informatico Robert C. Martin nel suo articolo pubblicato nel 2000.

Diamo un'occhiata all'acronimo SOLID:

(S) Principio di responsabilità unica ←

Una classe deve essere responsabile di un solo scopo, il che significa che una classe deve avere un solo tipo di lavoro da eseguire, ad esempio (logica del database, logica di registrazione e così via).

(O)penna/Principio chiuso ←

Una classe deve essere aperta per l'estensione ed essere chiusa per la modifica, il che significa che una classe esistente deve essere estendibile senza dover essere riscritta per implementare nuove funzionalità.

(L) Principio di sostituzione di iskov ←

Le classi padre devono essere facilmente sostituibili con le classi figlie, il che significa che se la classe Rectangle è un sottotipo della classe Shape, dovremmo essere in grado di sostituire Shape con Rectangle senza interrompere il flusso funzionale.

(I) Principio di segregazione delle interfacce ←

Le interfacce non devono forzare le classi a implementare funzionalità che non supportano, il che significa che le interfacce più grandi dovrebbero essere suddivise in interfacce più piccole per offrire supporto.

(D) Principio di inversione delle dipendenze ←

Le classi devono dipendere dall'astrazione ma non dalla concrezione, il che significa che i moduli di alto livello non devono dipendere da moduli di basso livello. Entrambi devono dipendere dall'astrazione.