oop... object whaaat?
DESCRIPTION
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.TRANSCRIPT
OOP... Object Whaaat?
A story of engineers, bricks and gears
by Diego Giorgini - @ogeidix
Quello che ci hanno insegnato a scuola non è tutto quello 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 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]
Ma come? ...ok, nel software?
Programmazione procedurale e strutturataParadigma 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 oggettiLa 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]
Ma come? ...ok, nel software?
Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
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!
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
Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
sono comunque ottimi:
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
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
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
Gli obiettivi che riusciamo a raggiungere
Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
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ò:
Gli obiettivi che riusciamo a raggiungere
Flessibilità di fronte al cambiamento Riuso reale del codice Mantenere il sistema aperto alla crescita
Scomposizione del problema in sotto problemi Suddivisione del lavoro in più sviluppatori Modularizzazione del progetto
Le necessità dello sviluppo software includono però:
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 diverse entità
Entità dinamiche
Permettono di modificare il comportamento del sistema inserendo nuove entità con comportamenti differenti
Il sistema è flessibile a nuoverichieste senza bisogno di modificare quanto realizzato
Entità dinamiche
“Il tuo design è corretto se ogni nuova modifica al progetto richiede meno codicedella modifica precedente”
Matteo Vaccari - @xpmatteo
Progettare entità dinamiche
Il diagramma delle classi? Statico!
Il comportamento viene descritto dal diagramma di collaborazione
Progettare entità dinamiche
Una automobile ... statica
Centralina
Ruota
RuotaMotrice
Volante
Pedale
Cruscotto
Luci
Class diagram:
1 1
1
1
1 12
2
1..*
1
3
1
Progettare entità dinamiche
:Centralina
RuotaMDx:RuotaMotrice
:Volante
Freno:Pedale
:Cruscotto
FrecciaDx:Luce
Stop:Luce
Una automobile ... statica - dinamica
Collaboration diagram:1: Accensione delle frecce
1.1 turn_on
1.2 turning_right2: Frenata2.1 turn_on
2.2 brake
2.2.1 brake
2.2.1 braking
comunica dati allericeveinformazioni da
Progettare entità dinamiche
Centralina
RuotaMotrice Volante
Pedale
Cruscotto
Luci
Una automobile ... statica - dinamica
Class diagram:
Comanda delle
comunica dati al riceve dati dal
ricevono dati dal
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
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’s skirt, code shouldn’t reveal too much of itself and shouldn’t be too nosy into others affairs”
Andy Hunt & Dave Thomas
Educazione verso gli altri oggetti
Tell the other guyoppure “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.
Progettiamo il comportamento delle entità
2. Devono essere educate verso il programmatore
Ask for things
Nel progetto sono presenti:1. aree di codice logico (business logic)2. aree di codice di inizializzazione (new keywords)
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)
Educazione verso i programmatori
Se queste due aree sono intersecate abbiamo:1. dipendenze nascoste al programmatore2. difficoltà nel realizzare test di unità
Avoid global state
Utilizzare uno stato globale mutabile porta a:1. Difficoltà di debugging e test2. API che mentono al programmatore
Educazione verso i programmatori
Avoid global state
Utilizzare uno stato globale mutabile porta a:1. Difficoltà di debugging e test2. API che mentono al programmatore
Educazione verso i programmatori
Attenzione a:1. Singleton = AntiPattern2. Hidden global state (Random, Date, Time)
3. *VM Global State VS Application global state4. Global state IS TRANSITIVE!
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 authoritative representation within a system.
Andy Hunt & Dave Thomas
Anti If Campaign
1. Difficile da leggere2. Difficile da testare3. Freno alla crescita del progetto
La maggior parte degli if può essere rimossa tramite Polimorfismo
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.
Predisposizione al cambiamento
Predisposizione al cambiamento
Composition instead of Inheritance
Be careful about runaway subclassing
... IT’S AGAIN STATIC!
Come realizzare ciò in modo sistematico
Refactoring = rimozione delle duplicazioniattraverso l’individuazione degli smell
Message chainsPrimitive obsession
CommentsLong method
Long class
Uncommunicative nameInconsistent names
Type embedded in nameLong method
Long parameter list
Magic numbersDuplicated codeDuplicated flow
Embedded expressionsConditionals
Bibliografia e approfondimenti
1. UML Tutorial: Collaboration Diagrams - Robert C. Martin2. Keep it DRY, Shy, and Tell the Other Guy - Dave Thomas3. Clean Code Talks - Misko Hevery4. 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/