Traditional:

libraries containing a large number of small building-blocks

Frameworks:

The Concept The highest common abstraction level among a number of similar products or applications to be captured in terms of general concepts and structures. This creates a generic design that can be instantiated for each existing product as well as for products to be developed and marketed in the future. Frameworks are ideally suited for capturing the commonalities in a product family. The bulk of the functionality can be captured in the framework, which is maintained as a single system. Each product is an instantiation of the framework, where the amount of unique code is proportional only the amount of specific features in that product and not to its total complexity. An object-oriented framework can be seen as a class library which is built on a systematic and extensive use of polymorphism or dynamic binding. That is easier said than done and the established development methods offer little support for framework design. But new method elements, such as patterns and contracts, are beginning to appear as valuable contributions to the evolution of OO methods. A framework is a reusable design for a specific category of applications, expressed as a set of cooperating classes. A software framework is a reusable mini-architecture that provides the generic structure and behavior for a family of software abstractions, along with a context of memes/metaphors which specifies their collaboration and use within a given domain. A framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes.

Q: What is the relationship between frameworks and design patterns? A: Frameworks are software whereas patterns are knowledge or information about software. Patterns can be used to describe frameworks and some part or aspect of a framework can be a realization of a pattern.

Q: What is the difference between an object-oriented framework and a class library? A: An object-oriented framework is a kind of class library. The distinguishing feature is that when the library is a framework the flow of control is bi-directional between the application and the library. This feature is achieved by the dynamic binding in object-oriented languages where an operation can be defined in a library class but implemented in a subclass in the application. Class library= Self contained, pluggable code Frameworks = Reusable, "semi-complete" applications Patterns = Problem, Solution, Context

Why Frameworks? The framework is not just a collection of classes but also defines a generic design. When you use the framework your re-use that design and save time and effort. Secondly, because of the bidirectional flow of control the framework can contain much more functionality than a traditional library regradless if it is a procedural or class library. Having to write less code also saves you time and effort.

Example An example of a framework is Model/View/Controller which was developed for graphical user interfaces. Swing uses this in Java.

What it takes: 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.)

The Problem The main obstacle to frameworks is the learning curve. To reuse a design you have to learn and understand it. This is never easy if the domain is non-trivial. Furthermore, no one has yet come up with a real good way to document a framework.