Friday, January 13, 2006
Frameworks
Overall, I'm happy with what I've seen. One of the engineers told me the framework "saved the day" in more than one big project. There is still room for improvement, but I guess we'll postpone all that for the next version, based on .NET.
There is always some kind of risk involved when you develop a framework. Statistically, the biggest risk is that the framework will not be used. My simple strategies to mitigate that risk include:
- Develop the core of the framework as part of real applications, then invest some effort to make it application-independent. Make sure you're solving real problems.
- Keep the framework small. If the scope is large, create several mini-frameworks. Keep the frameworks independent whenever possible, while (ideally) easy to integrate. Nobody wants to learn yet another huge framework.
- Involve future users (programmers) as much as possible. They will contribute ideas, learn the rationale behind the framework, and adopt it more readily.
Comments:
<< Home
giusto un appunto sul secondo punto: i framework di solito si basano sul template method e come meccanismo principale di riuso l'ereditarietà. In linguaggi dove è prevista solo l'ereditarietà singola come ottenere facilmente l' easy to integrate?
Il principale ostacolo (noto in pratica ed in letteratura) all'integrazione tra framework diversi (anche in C++) e' in realta' la pretesa di molti framework di detenere "il controllo" (es. message pump).
Quindi un primo step e' evitare che questo succeda.
Un altro step e' ovviamente avere una sana separation of concern tra i sottoframework, in modo tale che sia raro / inutile che una classe unica debba derivare da classi concrete appartenenti a framework diversi.
Dove si ipotizza questa necessita', se il linguaggio target e' limitato, la tecnica e' piu' o meno una sola (con varianti al contorno): replate inheritance with delegation, o in pattern speaking replace template method with strategy. Ovviamente strategy non da' accesso ai dati / metodi della classe base (cosa che avremmo con template method) e quindi in alcuni casi dobbiamo passare una ulteriore interfaccia come parametro di strategy, che espone dati / metodi della classe chiamante (e precedentemente base).
Niente di estremamente tragico :-)
Post a Comment
Quindi un primo step e' evitare che questo succeda.
Un altro step e' ovviamente avere una sana separation of concern tra i sottoframework, in modo tale che sia raro / inutile che una classe unica debba derivare da classi concrete appartenenti a framework diversi.
Dove si ipotizza questa necessita', se il linguaggio target e' limitato, la tecnica e' piu' o meno una sola (con varianti al contorno): replate inheritance with delegation, o in pattern speaking replace template method with strategy. Ovviamente strategy non da' accesso ai dati / metodi della classe base (cosa che avremmo con template method) e quindi in alcuni casi dobbiamo passare una ulteriore interfaccia come parametro di strategy, che espone dati / metodi della classe chiamante (e precedentemente base).
Niente di estremamente tragico :-)
<< Home
