A framework is a collection of
cooperating classes that make up a reusable design solution for a given problem
domain. It typically includes objects that provide default behavior, like
MacApp's menus and windows, and programmers use it by inheriting some of that
default behavior and overriding other behavior so that the framework calls
application code at the appropriate times.
There are three main differences between frameworks and class libraries:
- Behavior versus protocol. Class libraries are essentially collections
of behaviors that you can call when you want those individual behaviors in your
program. A framework, on the other hand, provides not only behavior but also the
protocol or set of rules that govern the ways in which behaviors can be combined,
including rules for what a programmer is supposed to provide versus what the
framework provides.
- Don't call us, we'll call you. With a class library, the code the
programmer writes instantiates objects and calls their member functions. It's
possible to instantiate and call objects in the same way with a framework--that
is, to treat the framework as a class library--but to take full advantage of a
framework's reusable design, a programmer writes code that overrides and is
called by the framework. The framework manages the flow of control among its
objects. Writing a program involves dividing up responsibilities among the
various pieces of software that get called by the framework rather than
specifying how the different pieces should work together. This relationship is
expressed by the principle: "Don't call us, we'll call you."
- Implementation versus design. With class libraries programmers reuse
only implementations, whereas with frameworks they reuse design. A framework
embodies the way a family of related programs or pieces of software work. It
represents a generic design solution that can be adapted to a variety of specific
problems in a given domain. For example, a single framework can embody the way a
user interface works, even though two different user interfaces created with the
same framework might solve quite different interface problems.
A framework often embodies specific domain expertise. Application code customizes
the framework in a way that solves a particular application problem within the
general domain of the problem the framework was designed to solve. In the case of
an application framework like MacApp, the expertise is in the domain of writing
programs for the Mac OS that display menus and windows and perform other basic
tasks consistently and reliably. In the case of a framework developed by a bank,
the domain expertise embodied in the framework might be how customer accounts or
certain kinds of financial transactions work. In this case, a programmer might
customize the framework to create specific kinds of accounts or financial
instruments.