Disegno del codice che usa Framework e librerie di 3ze parti


 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:

  1. 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


  2. 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 :   |  |  |  |

Print | posted @ Tuesday, August 5, 2008 12:55 AM

Comments have been closed on this topic.