OOP... Object Whaaat?A story of engineers, bricks and gears                                         by Diego Giorgini - @o...
Quello che ci hanno insegnato a scuola non è tuttoquello che serve per vincere la sfida...
La nostra sfida è costruire progetti complessi
Ma come?
Ma come? ...ok, nel software?Programmazione procedurale e strutturataParadigma di programmazione che prevede l’utilizzo ch...
Ma come? ...ok, nel software?Programmazione procedurale e strutturataParadigma di programmazione che prevede l’utilizzo ch...
Ma come? ...ok, nel software?
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Gli obiettivi che riusciamo a raggiungere   Scomposizione del problema in sotto problemi   Suddivisione del lavoro in più ...
Le necessità dello sviluppo software richiedono  Non moduli statici
Le necessità dello sviluppo software richiedono  Non moduli statici                            ma entità dinamiche
Entità dinamiche   L’attenzione è sul comportamento dinamico   Il progetto è il risultato della   collaborazione di divers...
Entità dinamichePermettono di modificare il comportamentodel sistema inserendo nuove entità concomportamenti differentiIl s...
Entità dinamiche   “Il tuo design è corretto se ogni nuova   modifica al progetto richiede meno codice   della modifica prec...
Progettare entità dinamicheIl diagramma delle classi? Statico!Il comportamento viene descritto daldiagramma di collaborazi...
Progettare entità dinamicheUna automobile          ... staticaClass diagram:                                  1          1...
Progettare entità dinamicheUna automobile            ... statica - dinamica                                               ...
Progettare entità dinamicheUna automobile               ... statica - dinamicaClass diagram:                  riceve      ...
Progettiamo il comportamento delle entità1. Devono essere educate tra di loro2. Devono essere educate verso il programmato...
Progettiamo il comportamento delle entità1. Devono essere educate tra di loro
Educazione verso gli altri oggetti  Keep it shy  “The best code is very shy.  Like a four-year old hiding behind a mother’...
Educazione verso gli altri oggetti Tell the other guy oppure “Tell, Don’t Ask” o “Send messages” Non devono preoccuparsi d...
Progettiamo il comportamento delle entità2. Devono essere educate verso il programmatore
Educazione verso i programmatori Ask for things Nel progetto sono presenti:  1. aree di codice logico (business logic)  2....
Educazione verso i programmatori Ask for things Nel progetto sono presenti:  1. aree di codice logico (business logic)  2....
Educazione verso i programmatori Avoid global state Utilizzare uno stato globale mutabile porta a:  1. Difficoltà di debugg...
Educazione verso i programmatori Avoid global state Utilizzare uno stato globale mutabile porta a:  1. Difficoltà di debugg...
Progettiamo il comportamento delle entità3. Devono essere predisposte per la collaborazione
Predisposizione al cambiamento DRY, Don’t Repeat Yourself Every piece of knowledge must have a single, unambiguous, and au...
Predisposizione al cambiamento Anti If Campaign 1. Difficile da leggere 2. Difficile da testare 3. Freno alla crescita    de...
Predisposizione al cambiamento Design Pattern Dividendo le responsabilità di comportamento permettono al sistema di evolve...
Predisposizione al cambiamento Composition instead of Inheritance Be careful about runaway subclassing ... IT’S AGAIN STAT...
Come realizzare ciò in modo sistematico     Refactoring = rimozione delle duplicazioni       attraverso l’individuazione d...
Bibliografia e approfondimenti 1. UML Tutorial: Collaboration Diagrams - Robert C. Martin 2. Keep it DRY, Shy, and Tell the...
Upcoming SlideShare
Loading in …5
×

OOP... Object Whaaat?

2,085 views

Published on

La programmazione orientata agli oggetti non è quella che vi hanno insegnato a scuola!

Vedremo assieme qual'è il significato di questo paradigma di programmazione, spesso frainteso, e i nuovi obiettivi che ci permette di raggiungere nello sviluppo software.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,085
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
14
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

OOP... Object Whaaat?

  1. 1. OOP... Object Whaaat?A story of engineers, bricks and gears by Diego Giorgini - @ogeidix
  2. 2. Quello che ci hanno insegnato a scuola non è tuttoquello che serve per vincere la sfida...
  3. 3. La nostra sfida è costruire progetti complessi
  4. 4. Ma come?
  5. 5. Ma come? ...ok, nel software?Programmazione procedurale e strutturataParadigma di programmazione che prevede l’utilizzo chiamate a blocchi di codice dettisubroutine o anche sottoprogrammi.Le subroutine possono inoltre essere associate a strutture dati così da mantenere allineatala struttura del programma con quella dei dati. [tratta da wikipedia]
  6. 6. Ma come? ...ok, nel software?Programmazione procedurale e strutturataParadigma di programmazione che prevede l’utilizzo chiamate a blocchi di codice dettisubroutine o anche sottoprogrammi.Le subroutine possono inoltre essere associate a strutture dati così da mantenere allineatala struttura del programma con quella dei dati. [tratta da wikipedia]Programmazione ad oggettiLa programmazione orientata agli oggetti (Object Oriented Programming, in breve OOP) èuno stile di programmazione che deriva da quello classico procedurale, e può essereconsiderato una sua estensione. Consiste essenzialmente nella creazione di strutturedati gerarchiche e combina i dati insieme alle operazioni che li manipolano [tratta da un sito internet]
  7. 7. Ma come? ...ok, nel software?
  8. 8. Gli obiettivi che riusciamo a raggiungere Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
  9. 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. 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. 11. Gli obiettivi che riusciamo a raggiungere Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
  12. 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. 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. 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. 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. 16. Gli obiettivi che riusciamo a raggiungere Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
  17. 17. Gli obiettivi che riusciamo a raggiungere Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progettoLe necessità dello sviluppo software includono però:
  18. 18. Gli obiettivi che riusciamo a raggiungere Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progettoLe necessità dello sviluppo software includono però: Flessibilità di fronte al cambiamento Riuso reale del codice Mantenere il sistema aperto alla crescita
  19. 19. Le necessità dello sviluppo software richiedono Non moduli statici
  20. 20. Le necessità dello sviluppo software richiedono Non moduli statici ma entità dinamiche
  21. 21. Entità dinamiche L’attenzione è sul comportamento dinamico Il progetto è il risultato della collaborazione di diverse entità
  22. 22. Entità dinamichePermettono di modificare il comportamentodel sistema inserendo nuove entità concomportamenti differentiIl sistema è flessibile a nuoverichieste senza bisogno dimodificare quanto realizzato
  23. 23. Entità dinamiche “Il tuo design è corretto se ogni nuova modifica al progetto richiede meno codice della modifica precedente” Matteo Vaccari - @xpmatteo
  24. 24. Progettare entità dinamicheIl diagramma delle classi? Statico!Il comportamento viene descritto daldiagramma di collaborazione
  25. 25. Progettare entità dinamicheUna automobile ... staticaClass diagram: 1 1 Volante Centralina 1 3 1 1 Pedale 2 1 1 Ruota 1 Cruscotto 2 1..* RuotaMotrice Luci
  26. 26. Progettare entità dinamicheUna 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. 27. Progettare entità dinamicheUna automobile ... statica - dinamicaClass diagram: riceve informazioni da comunica dati alle Centralina Pedale LuciComanda delle ricevono dati dal comunica dati al riceve dati dal RuotaMotrice Cruscotto Volante
  28. 28. Progettiamo il comportamento delle entità1. Devono essere educate tra di loro2. Devono essere educate verso il programmatore3. Devono essere predisposte per la collaborazione
  29. 29. Progettiamo il comportamento delle entità1. Devono essere educate tra di loro
  30. 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. 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. 32. Progettiamo il comportamento delle entità2. Devono essere educate verso il programmatore
  33. 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. 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. 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. 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. 37. Progettiamo il comportamento delle entità3. Devono essere predisposte per la collaborazione
  38. 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. 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. 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. 41. Predisposizione al cambiamento Composition instead of Inheritance Be careful about runaway subclassing ... IT’S AGAIN STATIC!
  42. 42. Come realizzare ciò in modo sistematico Refactoring = rimozione delle duplicazioni attraverso l’individuazione degli smell Message chains Uncommunicative name Magic numbersPrimitive 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. 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’attenzioneDiego Giorginitweet me @ogeidix http://www.fruktarbo.com Questo slide sono rilasciate Creative Commons BY 3.0 http://creativecommons.org/licenses/by/3.0/

×