High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
1
Refactoring: la teoria in pratica
Ing. R. Turco
2
Introduzione
Nell’Object Oriented mi sono sempre sforzato di verificare l’applicabilità di ogni teoria appresa,
così da poter riusare, tutto o parte di essa, in modo ripetibile e tracciabile: teoria, analisi,disegno, pattern, documentazione, etc.In questo articolo mi propongo di esporre, miscelando insieme, teorie apprese, esperienze
personali e riflessioni sull’argomento.
Il refactoring: la giusta definizione
Il refactoring mi ha sempre notevolmente affascinato per le sue notevoli potenzialità. Tuttaviaquando parliamo di refactoring è necessario definire bene cosa intendiamo.In [DR2] si è visto che per la fase di costruzione, sia per un
Rational Unified Process
o per altriprocessi produttivi come
Agile
o
Estreme Programming
, le iterazioni sono incrementali per lefunzionalità; mentre sono iterative a riguardo del codice appena realizzato.Il refactoring, quindi, potrebbe essere definito come
“la parte iterativa dell’iterazione di
processo produttivo, finalizzata a migliorare il codice, a renderlo stabile, riusabile, manutenibile
e flessibile, fermo restando il comportamento finale del codice stesso”
.Di per sé è già una grande definizione! Tuttavia questa definizione è solo una vista di unamedaglia a due facce!!Il refactoring è, in realtà, sia di
natura preventiva che adeguativa
, per cui parlerei
dell’esistenza di due tipi di refactoring:
Il “Design Refactoring”;
L’”Implementation Refactoring”.
Design Refactoring
Il Disegn Refactoring è finalizzato a migliorare il modello del disegno per ottenere stabilità,
riusabilità, manutenibilità e flessibilità del sistema. E’ preventivo, perché, se il sistemas’implementa secondo le sue direttive, si ottiene un prodotto che ha già in sé delle “b
est
practices”, grazie al disegno.
Il Design Refactoring, difatti, si basa essenzialmente su alcuni principi, che vedremo in seguito,
e sull’uso dei Pattern [DR5][DR6].
L’obiettivo del Design Refactoring è di tendere a migliorare la qualità del prodotto
poiché le
scelte vengono prese preventivamente nell’architettura e nel disegno (Pattern architetturali,
Design Pattern, etc) per cui si tende a ridurre il numero di errori del prodotto.Io applico il Design Refactoring appena dopo la modellazione UML a colori [DR3], perché con
quest’ultima tendo prima a capire il modello; poi col Design Refactoring, invece, tendo a
migliorare il sistema, introducendo gli adeguati Pattern architetturali ed i vari Design Pattern.Fermarsi solo alla modellazione UML a colori servirebbe solo ad individuare un modello cherispecchia la realtà, conferendogli stabilità, ma non si è ancora fatto nulla per problematiche di
riusabilità e flessibilità, che sono quelle per cui l’Object Oriented è ritenuto estremamente
valido.
3
Booch ha, inoltre, affermato che un modo per vedere
“la qualità di un sistema ben strutturato
è quello di osservare come i suoi disegnatori e implementatori abbiano applicato i concetti dei
Pattern”
.
Implementation Refactoring
L’Implementation Refactoring, in
vece, è per natura adeguativo.
Se è stato fatto un ottimo Design Refactoring, allora l’Implementation Refactoring si limita a
rinominare classi, variabili e metodi, spostare le classi di package, cambiare la visibilità diclassi, variabili e metodi, costruttori, aggiungere assert, etc. Alcuni principi che vedremo di
seguito sono prettamente tipici dell’Implementation Refactoring e di, conseguenza,
prettamente orientati alla manutenzione.
Design Refactoring o Implementation Refactoring?
La risposta è : en
trambi, nel loro giusto peso, secondo l’accezione di cui sopra.
Occorre scrivere il software solo quando si ha una chiara visione del modello, e, comunque,solo dopo averne fatto del sano Design Refactoring; per cui un Implementation Refactoringdovrebbe
essere di entità contenuta, al punto di poterlo sostenere facilmente nell’ambito diun’iterazione!
Inoltre se gli sviluppatori hanno uno strumento, con cui sono sia in grado di disegnare che
d’implementare (Vedi Together per Java o Rational Rose), l’atti
vità è possibile in maniera
integrata e secondo un continuo che porta dall’OOA all’ OOD e all’OOP.
Fig. 1
Anche se si dovessero ricevere dei requisiti imprevisti che possono impattare sull’architettura,
il consiglio è prima di modellare: è indispensabile! [DR3].
L’Implementation Refactoring assume maggiore peso solo per software non noto, ma anche
qui è possibile con degli strumenti fare il
reverse engineering
ed ottenerne il modello; poi
lavorare su esso, fare il forward engineering e l’implementazione di dettaglio. E’ un processo
continuo (fig. 1).
Modellazione e DesignRefactoringForward Engineeringe ImplementationRefactoringProdottoReverse Engineeringdel Modello ogenerazione delModello
Add a Comment