Il documento discute la programmazione orientata agli oggetti (OOP) come un'estensione della programmazione procedurale, evidenziando l'importanza della modularizzazione, della flessibilità e della riusabilità del codice. Viene sottolineata la necessità di progettare entità dinamiche e una comunicazione efficace tra oggetti per facilitare l'evoluzione dei progetti software. Inoltre, il documento tocca principi di design come la riduzione delle dipendenze e l'uso di pattern per favorire un codice chiaro e manutenibile.

1. OOP... Object Whaaat?
A story of engineers, bricks and gears
by Diego Giorgini - @ogeidix

2. Quello che ci hanno insegnato a scuola non è tutto
quello che serve per vincere la sfida...

3. La nostra sfida è costruire progetti complessi

4. Ma come?

5. Ma come? ...ok, nel software?
Programmazione procedurale e strutturata
Paradigma di programmazione che prevede l’utilizzo chiamate a blocchi di codice detti
subroutine o anche sottoprogrammi.
Le subroutine possono inoltre essere associate a strutture dati così da mantenere allineata
la struttura del programma con quella dei dati.
[tratta da wikipedia]

6. Ma come? ...ok, nel software?
Programmazione procedurale e strutturata
Paradigma di programmazione che prevede l’utilizzo chiamate a blocchi di codice detti
subroutine o anche sottoprogrammi.
Le subroutine possono inoltre essere associate a strutture dati così da mantenere allineata
la struttura del programma con quella dei dati.
[tratta da wikipedia]
Programmazione ad oggetti
La programmazione orientata agli oggetti (Object Oriented Programming, in breve OOP) è
uno stile di programmazione che deriva da quello classico procedurale, e può essere
considerato una sua estensione. Consiste essenzialmente nella creazione di strutture
dati gerarchiche e combina i dati insieme alle operazioni che li manipolano
[tratta da un sito internet]

7. Ma come? ...ok, nel software?

8. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto

9. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
Sono gli stessi obiettivi raggiunti
dalla programmazione procedurale!

10. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
Sono gli stessi obiettivi raggiunti
dalla programmazione procedurale!
Stiamo facendo programmazione procedurale con
una sintassi diversa

11. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto

12. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
sono comunque ottimi:

13. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
sono comunque ottimi:
per realizzare un progetto definito

14. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
sono comunque ottimi:
per realizzare un progetto definito
per un progetto che resta fisso nel tempo

15. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
sono comunque ottimi:
per realizzare un progetto definito
per un progetto che resta fisso nel tempo
Purtroppo non stiamo costruendo un palazzo

16. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto

17. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
Le necessità dello sviluppo software includono però:

18. Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi
Suddivisione del lavoro in più sviluppatori
Modularizzazione del progetto
Le necessità dello sviluppo software includono però:
Flessibilità di fronte al cambiamento
Riuso reale del codice
Mantenere il sistema aperto alla crescita

19. Le necessità dello sviluppo software richiedono
Non moduli statici

20. Le necessità dello sviluppo software richiedono
Non moduli statici
ma entità dinamiche

21. Entità dinamiche
L’attenzione è sul comportamento dinamico
Il progetto è il risultato della
collaborazione di diverse entità

22. Entità dinamiche
Permettono di modificare il comportamento
del sistema inserendo nuove entità con
comportamenti differenti
Il sistema è flessibile a nuove
richieste senza bisogno di
modificare quanto realizzato

23. Entità dinamiche
“Il tuo design è corretto se ogni nuova
modifica al progetto richiede meno codice
della modifica precedente”
Matteo Vaccari - @xpmatteo

24. Progettare entità dinamiche
Il diagramma delle classi? Statico!
Il comportamento viene descritto dal
diagramma di collaborazione

25. Progettare entità dinamiche
Una automobile ... statica
Class diagram:
1 1 Volante
Centralina 1 3
1 1 Pedale
2 1 1
Ruota 1 Cruscotto
2
1..*
RuotaMotrice Luci

26. Progettare entità dinamiche
Una automobile ... statica - dinamica
Collaboration diagram:
1: Accensione delle frecce
FrecciaDx:Luce 1.1 turn_on
:Volante
Stop:Luce 2.1 turn_on
2: Frenata 1.2 turning_right
2.2 brake
Freno:Pedale
:Centralina
2.2.1 brake
2.2.1 braking
RuotaMDx:RuotaMotrice :Cruscotto

27. Progettare entità dinamiche
Una automobile ... statica - dinamica
Class diagram:
riceve
informazioni da comunica dati alle
Centralina Pedale Luci
Comanda delle ricevono dati dal
comunica dati al riceve dati dal
RuotaMotrice Cruscotto Volante

28. Progettiamo il comportamento delle entità
1. Devono essere educate tra di loro
2. Devono essere educate verso il programmatore
3. Devono essere predisposte per la collaborazione

29. Progettiamo il comportamento delle entità
1. Devono essere educate tra di loro

30. Educazione verso gli altri oggetti
Keep it shy
“The best code is very shy.
Like a four-year old hiding behind a mother’s
skirt, code shouldn’t reveal too much of itself
and shouldn’t be too nosy into others affairs”
Andy Hunt & Dave Thomas

31. Educazione verso gli altri oggetti
Tell the other guy
oppure “Tell, Don’t Ask” o “Send messages”
Non devono preoccuparsi di sapere con chi
stanno parlando o come sarà svolta la richiesta
che hanno invocato.
Devono limitarsi a comunicare “gentilmente” il
loro bisogno al vicino.

32. Progettiamo il comportamento delle entità
2. Devono essere educate verso il programmatore

33. Educazione verso i programmatori
Ask for things
Nel progetto sono presenti:
1. aree di codice logico (business logic)
2. aree di codice di inizializzazione (new keywords)

34. Educazione verso i programmatori
Ask for things
Nel progetto sono presenti:
1. aree di codice logico (business logic)
2. aree di codice di inizializzazione (new keywords)
Se queste due aree sono intersecate abbiamo:
1. dipendenze nascoste al programmatore
2. difficoltà nel realizzare test di unità

35. Educazione verso i programmatori
Avoid global state
Utilizzare uno stato globale mutabile porta a:
1. Difficoltà di debugging e test
2. API che mentono al programmatore

36. Educazione verso i programmatori
Avoid global state
Utilizzare uno stato globale mutabile porta a:
1. Difficoltà di debugging e test
2. API che mentono al programmatore
Attenzione a:
1. Singleton = AntiPattern
2. Hidden global state (Random, Date, Time)
3. *VM Global State VS Application global state
4. Global state IS TRANSITIVE!

37. Progettiamo il comportamento delle entità
3. Devono essere predisposte per la collaborazione

38. Predisposizione al cambiamento
DRY, Don’t Repeat Yourself
Every piece of knowledge must have a single,
unambiguous, and authoritative representation
within a system.
Andy Hunt & Dave Thomas

39. Predisposizione al cambiamento
Anti If Campaign
1. Difficile da leggere
2. Difficile da testare
3. Freno alla crescita
del progetto
La maggior parte degli if può essere rimossa
tramite Polimorfismo

40. Predisposizione al cambiamento
Design Pattern
Dividendo le responsabilità di comportamento
permettono al sistema di evolvere secondo
differenti direzioni.
Permettono di intervenire su di un particolare
aspetto della struttura del sistema in modo
indipendente dagli altri aspetti.

41. Predisposizione al cambiamento
Composition instead of Inheritance
Be careful about runaway subclassing
... IT’S AGAIN STATIC!

42. Come realizzare ciò in modo sistematico
Refactoring = rimozione delle duplicazioni
attraverso l’individuazione degli smell
Message chains Uncommunicative name Magic numbers
Primitive obsession Inconsistent names Duplicated code
Comments Type embedded in name Duplicated flow
Long method Long method Embedded expressions
Long class Long parameter list Conditionals

43. Bibliografia e approfondimenti
1. UML Tutorial: Collaboration Diagrams - Robert C. Martin
2. Keep it DRY, Shy, and Tell the Other Guy - Dave Thomas
3. Clean Code Talks - Misko Hevery
4. Design Patterns - Gang of four
Grazie dell’attenzione
Diego Giorgini
tweet me @ogeidix http://www.fruktarbo.com
Questo slide sono rilasciate Creative Commons BY 3.0 http://creativecommons.org/licenses/by/3.0/