Tag: principi s.o.l.i.d.

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

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

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.