Anti pattern se lo conosci lo eviti

L'Anti-Pattern:
se lo conosci lo eviti
Giorgio Vinci
Senior Consultant
g.vinci@k-tech.it
Simone Federici
Java Architect
s.federici@k-tech.it
Jug Roma 9° Meeting
25 Gennaio 2006
Eventi precedenti
18 novembre 2006 Novara
30 Settembre 2006 Verona
26 Giugno JC 2006 Milano

www.javaportal.it s.federici@k-tech.it & g.vinci@k-tech.it 2
AGENDA
●Introduzione
●GRASP
●Anti Pattern di Progetto
●I Mostri
●Come fare per difendersi
●Ringraziamenti

Spaghetti Code

Antipatterns Map

L'antipattern:
L'antipattern si può definire "pattern" in quanto è una soluzione progettuale generale a un
problema ricorrente ed è costituito da un nome, un problema ed una soluzione.
La differenza tra un normale pattern (o "Pattern Migliorativo") ed un Anti-Pattern è che il
primo è caratterizzato da una soluzione fondamentalmente buona/positiva, mentre il
secondo è caratterizzato da una falsa soluzione o da una soluzione fondamentalmente
negativa.
Verranno illustrati i principali Anti-Pattern, con le relative soluzioni alternative, all'interno del:
Project management, Design, Object-oriented programming e Developing.
Seguendo questa presentazione sarà possibile evitare la maggior parte degli Anti-Pattern ed
utilizzare invece un approccio sano alla progettazione e sviluppo del software. Laddove non
fosse possibile "risolvere" l'Anti-Pattern, sarà fondamentale essere in grado di evidenziarlo e
monitorarlo come criticità di progetto.

OBIETTIVI
Sottolineare l'importanza di una buona conoscenza dei
pattern e degli antipatterns, al fine di aver un approccio
sano alla progettazione e allo sviluppo del software
Lo speech è rivolto a:
Project Manager, Analisti, Architetti, Programmatori
perché la valenza dell'antipattern è trasversale al ruolo.

AGENDA
●Introduzione
●GRASP
●I Mostri
●Ringraziamenti

GRASP
General Responsibility Assignment Software
Pattern (or Principles)
●Information Expert
●Low Coupling
●High Cohesion
●Creator
●Controller
●Polymorphism
●Pure Fabrication
●Indirection
●Don't Talk to Strangers: (Law of Demeter)

GRASP
Information Expert
Low Coupling e High Cohesion
Dobbiamo distribuire le responsabilità a gli oggetti del
nostro dominio.
Information Expert ci dice di assegnare le responsabilità
all'oggetto più esperto, che possiede le informazioni.
Il basso accoppiamento ci dice di legare i componenti tra
loro il MINIMO indispensabile.
L'alta coesione ci dice che ogni Oggetto deve delle
responsabilità “COESE” tra loro, che abbiano un motivo
in comune per appartenere ad esso.

GRASP
Creator, Controller
Polymorphism
Quale è il principio generale per l'assegnazione
della responsabilità di creazione degli oggetti?
Come far comunicare l'UI con la BL?
A chi assegnare tale responsabilità?
La logica condizionale if-then-else spesso rende
difficile l'estensione dell'applicazione. Come
fare?

GRASP
Indirection, Pure Fabrication,
Don't Talk to Stranger
Non vogliamo accoppiare direttamente due oggetti,
posso delegare le responsabilità ad un oggetto tra loro?
Non riesco a non violare Low Coupling e High Coesion
con gli oggetti appartenenti al dominio del problema,
come fare?
Come evitare che oggetti disegnati secondo la Low
Coupling diventino accoppiati nell'implementazione?

AGENDA
●Introduzione
●GRASP
●I Mostri
●Ringraziamenti

SCACCHIERA
Un caso reale... o quasi.
Immaginiamo di dover realizzare il gioco degli scacchi.

Gas Factory
Mettiamo in piedi un sistema di intelligenza
artificiale.
Creiamo un pannello di controllo per una
gestione parametrica dell'intera
applicazione.
E aggiungiamo la possibilità di giocare in
rete...
Tutte cose bellissime ma che
non ci erano state chieste!!!

Reinventing
the wheel
Mi invento un mio metodo per
L'auto apprendimento del programma a
giocare a scacchi
Ignorando l'esistenza di Reti Neurali,
Apprendimento Bayesiano ecc...

Abstract Inversion
Un interfaccia troppo povera rischia di
nascondere alcune funzionalità.
Scacchiera
+trasformazione()
+arrocco()
Pezzo
<<interface>>
+muovi()
+mangia()
+...()
Pedone
+trasformazione()
Regina
Torre
Cavallo
Alfiere
Re
+arrocco()

Interface bloat
"In medio stat virtus"
Un interfaccia troppo ricca comporta che la maggior parte degli oggetti non
saranno in grado di implementare molte delle funzionalità.
Oltre a violare il principio di alta coesione.

Re-Coupling
Abbiamo introdotto una
dipendenza non
necessaria
Assegnando
correttamente le
responsabilità evitiamo
un eccessivo
accoppiamento

Magic Pushbutton
All'interno dei metodi Drag&Drop della
nostra interfaccia grafica andiamo a
“cablare” la logica di business.
Il metodo del listener conterrà:
- verifica validità della mossa
- movimento del pezzo
- eventuale rimozione di pezzo avversario
...

Poltergeist
Ad ogni
invocazione
della UI
generiamo un
opportuno
controller che
si occupa di
interfacciarsi
con i business
object

God Object
Secondo il principio
dell'Information Expert
potremmo arrivare a
disegnare una classe
che si occupa di tutto...

AGENDA
●Introduzione
●GRASP
●I Mostri
●Ringraziamenti

I MOSTRI
Spaghetti code
Cut and Paste programming
Golden Hammer
Input Kludge
Coding by exception
Blind faith
Hard code
Busy waiting or spinning

AGENDA
●Introduzione
●GRASP
●I Mostri
●Ringraziamenti

LA MIGLIOR DIFESA è
L'ATTACCO
(Trovalo prima che lui trovi te)
Object Oriented Programming
Principi/Pattern GRASP
Design Pattern GOF
Antipatterns
Code Convention
Java BluePrints
Conoscere i tools

Structural Analysis
Tangle
Butterfly
Breakable
Hub
Implementation Dependency

FindBugs
Impossibili Cast
Clonable
Empty File
instanceof sempre false
logica Sempre false
compareTo
Exception Droppate
Date (parametri esempio mesi 0-11)
Iteretor bad use hasNext() next()
HARDCODED_ABSOLUTE_FILENAME
No Serializable
OVERWRITTEN_INCREMENT
System.exit(...) (DM_EXIT)
equals() used to compare array and nonarray
equals() comparing different interface
Explicit invocation of finalizer()
Initialization circularity
apparent infinite recursive loop
Store of non serializable object into HttpSession
Null pointer dereference in method
Read of unwritten field
Confusing method names
Method may fail to close database resource
Method may fail to close stream
Redundant comparison of non-null value to null
Invalid syntax for regular expression
SQL_BAD_PREPARED_STATEMENT_ACCESS
Possible double check of field
A thread was created using the default empty run method
Inconsistent synchronization
Mismatched notify()

CheckStyle
Jalopy
J2EE Task
Correttezza degli EJB
Task Code convention
Task customizzabili

Controlli automatici
Nei processi di build automatici
è possibile aggiungere i plugin di findbugs
e checkstyle
Maven2
ANT
E' possibile anche lanciare jalopy
(prima di un rilascio)

TOOLS
Structural Analysis
Jdepend
findbugs
checkstyle
jalopy/jacobe
Maven
Ant
Plugin per gli IDE

AGENDA
●Introduzione
●GRASP
●I Mostri
●Ringraziamenti

Le tappe JavaDay 2006!
Torino 7 Luglio
Verona 30 Settembre
Pisa 14 Ottobre
Novara 18 Novembre
Palermo 24 Novembre
Cagliari 25 Novembre
Roma 02 Dicembre
http://www.javaday.it
http://roma.javaday.it

Le tappe JavaDay 2007!
?
http://www.javaday.it
http://roma.javaday.it

Ringraziamenti
www.javaportal.it
www.javaday.it
www.jugroma.it
roma.javaday.it

References
www.javaportal.it
www.antipatterns.com
www.ugolandini.net
http://c2.com/cgi/wiki?AntiPatternsCatalog
http://en.wikipedia.org/wiki/Antipattern
http://java.sun.com/reference/blueprints/
http://java.sun.com/docs/codeconv/
http://findbugs.sourceforge.net/
http://checkstyle.sourceforge.net/
http://jalopy.sourceforge.net/
http://www.tiobe.com/jacobe.htm
http://freshmeat.net/projects/structuralanalysisforjava/
http://www.clarkware.com/software/JDepend.html
http://ant.apache.org/
http://maven.apache.org/

Anti pattern se lo conosci lo eviti

More Related Content

Viewers also liked

Similar to Anti pattern se lo conosci lo eviti

More from Simone Federici

Anti pattern se lo conosci lo eviti