Object Oriented Design - I principi SOLID

1. Object Oriented Design
Alessandro Ceseno
contact me, my website is: www.alexceseno.it
Add me on Linkedin:
http://www.linkedin.com/in/alessandroceseno

2. I PRINCIPI SOLID
Single Responsibility Principle - SRP
Una classe dovrebbe avere una sola e una sola ragione al cambiamento.
Ogni classe, ogni modulo sw dovrebbe avere una e una sola responsabilità.
Responsabilità diverse implicano classi diverse.
Questo principio è chiamato coesione.

3. È un semplice principio ma anche un principio difficile da attuare.
Trovare e separare le responsabilità degli oggetti è l’obbiettivo del Design.
Alcune volte si utilizzano i Design Pattern DAO, Facade, Proxy.
Il Single Responsability Principle è uno dei più semplici principi di design da
capire ma anche da attuare.

4. Open Close Principle
Si dovrebbe essere in grado di estendere un comportamento senza
modificare il comportamento esistente.
Quindi si dovrebbe essere in grado di estendere una classe senza
modificarla.
Tutte le variabili di una classe dovrebbero essere private.

5. Dovrebbero esserci meno variabili globali possibili, ovvero limitare al
massimo la visibilità delle variabili.
Tutte le entità software devono essere:
- aperte alla estensione
- chiuse alle modifica delle stesse
Spesso si riescono creare astrazioni che rappresentano le classi base e
successive classi derivate che rappresentano il comportamento
specializzato.

6. Liskov Substitution Principle
Il principio di sostituzione di Liskov è una nozione basata sulla sostitubilità.
Se S è un sottotipo di T allora un oggetto di tipo T può essere sostituito con
un oggetto di tipo S senza alterare qualsiasi altra parte del programma.
Questo principio tratta l’ astrazione dei dati e la gerarchia delle classi.
Questo principio tratta più la relazione sintattica piuttosto che la relazione
sintattica della classe, perchè garantisce l’ interoperatività semantica dei tipi
della gerarchia.

7. Questo principio definisce una nozione di sostituibilità di oggetti mutabili.
Il principio di Liskov impone alcuni requisiti standard sulla Signature dei
metodi che sono state adottate nei linguaggi di programmazione Object
Oriented:
Controvarianza di argomenti del metodo nel sottotipo.
Covarianza di tipi restituiti nel sottotipo.
Nessuna nuova eccezione dovrebbe essere lanciata dai metodi dei
sottotipo, ad eccetto di quelle eccezioni che sono già sottotipi lanciate dai
metodi del supertipo.

8. Nota:
Si ha covarianza se si conserva l'ordinamento di tipi, ovvero si ha un
ordinamento dei tipi dai più tipi specifici a più generico.
Si ha controvarianza se si inverte questo ordinamento.

9. Interface Segregation Principle
Questo principio evidenzia lo svantaggio di avere interfacce che non sono
interfacce specifiche per un singolo client.
Sono chiamate interfacce “fat” ovvero le interfacce che non rispettono la
coesione ed hanno un alto accoppiamento. Queste interfacce possono
essere scomposte e ciascun componente può servire un diverso set di
client.
Le interfacce “fat” possono essere segregate in classi astratte che vanno a
togliere il non voluto accoppiamento tra le classi.

10. Dependency Inversion Principle
Moduli di alto livello non dovrebbero dipendere da moduli di basso livello.
Entrambi dovrebbero dipendere dall’ astrazione.
L’ astrazione non dovrebbe dipendere dai dettagli.
I dettagli non dovrebbero dipendere dall’ astrazione.

11. Perchè la parola inversione?
I metodi di sviluppo software più tradizionali come metodologie di analisi
strutturata e design tradizionale tendono a creare design con un alta
dipendenza dei moduli di alto livello con i moduli di basso livello e nelle
quali le astrazioni dipendono anche dai dettagli.
L’ obbiettivo di queste metodologie è definire gerarchie di sottoprogrammi
che descrivono come i moduli di alto livello chiamano i moduli di basso
livello. Si hanno strutture gerarchiche.
Attraverso la DIP questo approccio è invertito rispettando la struttura delle
dipendenze che normalmente risulta dalle metodologie tradizionali.

12. Quando si crea un cattivo Design?
Rigidità
È difficile effettuare una modifica al codice poichè ogni cambiamento ha
impatto su molte altre parti del sistema.È l’ interdipendenza dei moduli
all’interno del design. Un design è rigido se esso non può essere cambiato
facilmente.
Tale rigidità è dovuta al fatto che tale cambiamento ha una pesante
interdipendenza software tra moduli che dovrebbero essere indipendenti.

13. Fragilità
Quando cambi il codice e inaspettatamente parti del codice si rompono.
La fragilità è la tendenza di un programma di rompersi in moti posti quando
si fa un seplice cambiamento.
Quando semplici cambiamenti di una parte dell’ applicazione crea problemi
in altre parti dell’ applicazione apparentemente senza relazione.

14. Immobilità
È difficile da riutilizzare il componente software in un’ altra applicazione
perchè non può essere spostato ed avere la stessa efficacia.
Un design è immobile quando parte del design ha un’ alta dipendenza dai
dettagli.

15. BIBLIOGRAFIA/SITOGRAFIA:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

16. Object Oriented Design
Alessandro Ceseno
contact me, my website is: www.alexceseno.it
Add me on Linkedin:
http://www.linkedin.com/in/alessandroceseno