A framework is a set of classes that embodies an abstract design for solutions to a family of related problems (RalphJohnson and B. Foote, Journal of Object-Oriented Programming 1(2), 1988).

You can specialize and/or instantiate these classes to implement an application or subsystem. Typical issues:

  • Frameworks adopt an inverse control flow, sometimes called the Holywood Principle (don't call us, we'll call you): in contrast with a library, the methods you define to use the framework get called by the framework (for example through call backs or inheritance).
  • Design patterns can be used to document the structure of frameworks -- for example IBM's San Francisco relies on the ModelViewControler? pattern.
  • The interface between the framework and the application-specific parts built on top of it is realized as a set of extension points, or hot spots.


A well known industrial framework is IBM's San Francisco

The relationship between frameworks and DomainSpecificLanguages is explored in:

Both are discussed in the DSLAnnotatedBibliography as well.

CategoryArchitecture | Contributions by ArieVanDeursen

Revision: r1.10 - 02 Jan 2002 - 14:11 - ArieVanDeursen
Transform > ObjectOrientedFramework
Copyright © 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback