(ootips) Writing Frameworks - What Does It Take?

Writing Frameworks - What Does It Take?

Source: otug@rational.com
Date: 15-Apr-98

Problem: A framework is a reusable design for a specific category of applications, expressed as a set of cooperating classes.
What does it take to write a framework?

Michael A. Beedle wrote:

In our experience we have found that you need to:

Be an expert in the domain (learning fast might not be enough, because there are many subtleties that one only understands with years of experience in the same domain).
Understand the user community and their priorities well, and at the same time be persuasive enough not to let the short term user schedules ruin the framework.
Communicate with the user community extremely well.
Be an expert in OO modeling.
Be an expert in design and architectural patterns.
Have the backing from upper management to support the expensive initial iterations, because when you develop frameworks, by definition, you have to pay some of the cost up front so that you can save money in the long term. [...]
Be willing to experiment and even fail in your first attempts. This really means be willing to "throw some out".
Have a solid infrastructure. Have all the architectural mechanisms/services in place before you attempt to write a framework (logging, distribution, persistence, event service, naming service, etc.)

Writing frameworks and applications is about controlling two concurrent processes:

architectural management (refactoring of the framework)
application development (iterative/incremental cycle)

These two processes weave into one another and through self-consistency deliver both the applications and the framework.

[Integrating these two processes together] result in [two] organizational structures: the architectural team and the client or application development team. If you lean too much on the application side you end up with the "stove-pipes" syndrome (your architecture followed the use cases too strongly). [...] If you lean too much on the architectural side, you end up in the "incongruent architecture" syndrome, your architecture will not match your requirements needs. [...]

"4)" [OO expertise] and "5)" [patterns expertise] above are not the same thing. "4)" means finding the correct semantic relationships and using the correct modeling techniques among abstract domain classes (something I call the framework "high" points). "5)" means applying advanced design techniques to implement the leaf classes around the abstract "hot spots" == the things that change. [...]

However, this will only get you a "white box" framework.

After this, you will have to parameterize it in order to convert it into a "black box" framework. (Here is where you add the parameterized factories that initialize the framework all over the place given some configuration.)

Check out "Patterns for Evolving Frameworks", the paper that Don Roberts and Ralph Johnson wrote [...]. It has many good insights on how to write frameworks. [see More Info -YS]

More Info:

Ralph Johnson's Frameworks page

Taligent, Building Object-Oriented Frameworks

Don Roberts & Ralph Johnson, Evolving Frameworks - A Pattern Language for Developing Object-Oriented Frameworks

B?umer, Gryczan, Knoll, Lilienthal, Riehle & Z?llighoven, Framework Development for Large Systems

Andr? Weinand & Erich Gamma, ET++ - a Portable, Homogeneous Class Library and Application Framework