««« | »»»
Contro i frameworks?
Se dò una scorsa ai libri sugli scaffali ne trovo diversi che parlano dei frameworks e delle loro virtù, a partire dal venerabile Design patterns. Cito:
The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and object collaborate, and the thread of control. A framework predefines these design parameters so that you, […], can concentrate on the specifics of your application.
[…]
Reuse on this level leads to an inversion of control between the application and the software on which it’s based.
D’altra parte, come forse ricordano quelli che si sono dati la pena di leggere i miei pensieri sul mapping OR, sanno che non li ho più in gran simpatia.
Frameworks vs librerie
Il motivo fondamentale è che c’è una tensione irriducibile fra il riutilizzo (di codice, di impostazioni, di patterns) promosso da un framework e la relazione inversa fra estensione del codice e riutilizzabilità.
Più il framework è esteso meno è efficiente, dove, in questo contesto, l’efficienza è data dalla estensione rispetto alla porzione realmente utilizzata.
Inoltre – e soprattutto – un framework nasce con la premessa che l’inversione di controllo 1 sia una buona cosa. Ma è poi vero?
Se siamo incerti sul da farsi un framework risulta prezioso perché, in un certo senso, non possiamo sbagliare, appunto grazie all’inversione di controllo che detterà a grandi linee i punti in cui inserirci. Viceversa, una libreria “normale” funge da semplice deposito di codice che viene chiamato dall’applicazione, nei modi e nei tempi ritenuti opportuni.
Quando e come conviene usare un framework?
A mio parere, un framework risulta vantaggioso con un progetto nuovo, dove è importante riuscire ad arrivare ad un risultato nel minor tempo possibile ma, idealmente, sarebbe da considerare come un’impalcatura che verrà smontata quando non è più necessaria.
Più facile a dirsi che a farsi, certo, ma non è raro che dopo una prima release un’applicazione venga riscritta senza i framework usati in precedenza, spesso per ragioni di prestazioni.
- cito ancora:
Reuse on this level leads to an inversion of control between the application and the software on which it’s based. When you use a toolkit, you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls.
Per proseguire
Commenti e trackback sono disabilitati.