Sun per Java e Microsoft per .NET hanno un framework esteso che soddisfa molte delle esigenze comuni nello sviluppo di software. E ci sono anche varie librerie di 3ze parti che capita di usare nelle proprie applicazioni.
Questo può portare a realizzare codice composto da una sequenza di chiamate a librerie / framework, difficile da testare e difficile da capire. In passato mi è capitato di scrivere codice in questo modo e di trovare codice fatto cosi e non è stato facile lavorarci.
L'altro svantaggio è la dipendenza inestricabile che si crea con il framework o la libreria. E questo ha un impatto economico e strategico tangibile. Perchè le librerie e i framework cambiano ed evolvono e a volte si vorrebbe cambiare libreria ma il codice non lo permette o lo rende insostenibile per tempi e costi.
Mi è capitato ad esempio di voler passare da ODBC a OleDb e da OleDB ai .NET Data Provider, di voler passare dal GDI al GDI+ di .NET, di voler sostituire la libreria di controlli usata per disegnare i grafici con un'altra libreria più evoluta e con un meccanismo di licenza più conveniente.
In Working Effectively with legacy code di M.C.Feathers ho trovato l'indicazione di evitare di inserire le chiamate dirette nel codice e invece wrappare le chiamate con delle classi. GLi approcci suggeriti sono essenzialmente 2:
- Skin and Wrap the API
cioè sradica le chiamate alle API e avvolgi la libreria con dei Wrapper quasi identici che la sostituiscono - sullo stile del PatternAdapter - il wrapper tipicamente rappresenta chiamate 1:1 con la libreria e non aggiunge logica
- Responsability-Based extraction
estrai le chiamate alle API raggruppandole in base alle responsabilità che assolvono nella tua applicazione componendo cosi dei nuovi metodi - sullo stile del PatternBridge e del PatternFacade - in queto caso il facade o il bridge possono contenere anche nuova logica
Skin and Wrap the API è preferibile quando le API della libreria sono relativamente piccole, si vuole eliminare completamente dal dipendenza dalla libreria o dal framework di 3ze parti, non è possibile scrivere test sul codice che chiama le API.
Responsability-Based extraction è preferibile quando le API della libreria sono più complicate e disponi di un tool di refactoring che ti facilita l'estrazione di metodi.
Molti team impiegano entrambe le tecniche insieme, un wrapper sottile (PatternAdapter) per poter testare e una wrapper di più alto livello (PatternBridge e PatternFacade) per fornire una interfaccia migliore alla propria applicazione.
Tags :
Team Work |
Agile |
Pratiche |
Progettazione Software |