Principi S.O.L.I.D.

“Cosa sono i principi SOLID? Riesci a spiegarmeli in maniera semplice?”

Questa domanda mi è stata posta alcuni giorni fa da uno programmatore con “esperienza”,che da alcuni anni sviluppa in .NET.

Bella domanda!

Tendenzialmente i programmatori (me compreso!) sono orientati alla scrittura di codice, non a pensare a cosa/come lo stanno scrivendo.
Questo tipo di approccio è un pò quello che arriva dal mondo della scuola, dove vengono insegnati i linguaggi di programmazione come Javascript, C# e Angular, ma non vengono affrontati i principi della buona programmazione.

Continua a leggere Principi S.O.L.I.D.

I principi S.O.L.I.D. – Conclusioni

Siamo giunti al termine degli articoli legati ai principi S.O.L.I.D.

Riassumendo, questi principi sono molto utili durante la programmazione orientata agli oggetti (ODD). Sono stati enunciati da Robert Martin (conosciuto anche come zio Bob) e sono delle linee guida per lo sviluppo ed il refactoring di codice.

Continua a leggere I principi S.O.L.I.D. – Conclusioni

I principi S.O.L.I.D – DIP

L’ultimo principio S.O.L.I.D. è il  Dependency Inversion Principle (D).

Questo principio rappresenta la separazione tra i moduli/classi di alto livello rispetto ai moduli/classi di basso livello. In pratica, tutto dovrebbe dipendere da astrazioni e non dalle loro implementazioni.

Possiamo considerare i metodi/classi di basso livello come la parte core delle nostre applicazioni: si occupano di effettuare, ad esempio,  letture/scrittura su database, accesso ai dati e persistenza su file. I moduli/classi di alto livello implementano la parte di Business Logic, ovvero la logica dell’applicazione. Continua a leggere I principi S.O.L.I.D – DIP

I principi S.O.L.I.D. – ISP

Interface Segregation Principle (ISP):

Ogni client non deve implementare interfacce che non usa. Invece di strutturare i moduli implementando un’unica interfaccia, è preferibile organizzare il nostro progetto con interfacce separate (e quindi moduli separati).

Come per le classi (dal principio SRP visto in precedenza) anche le interfacce dovrebbero essere definite per specifiche responsabilità. Quando una classe non necessità di una specifica funzionalità, non è necessario implementarla. Maggiore è il numero di metodi definiti all’interno di un’interfaccia, e maggiore sarà la probabilità che non siano utilizzati. Continua a leggere I principi S.O.L.I.D. – ISP

I principi S.O.L.I.D. – LSP

Il terzo principio S.O.L.I.D. riporta: “You should be able to use any derived class instead of a parent class and have it behave in the same manner without modification“.

Si tratta un’estensione del secondo principio (OSP), e implica la necessità di estendere le classi base senza modificarne il loro comportamento originale.

Una soluzione possibile per poter soddisfare questo principio, è quella di effettuare refactoring.