Patterns Vs Framework:

One thing closely related to design patterns and object-orientation is a software framework :

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 metaphors which specifies their collaboration and use within a given domain.

The framework accomplishes this by hard coding the context into a kind of "virtual machine" (or "virtual engine"), while making the abstractions open-ended by designing them with specific plug-points (also called hot spots). These plug-points (typically implemented using callbacks, polymorphism, or delegation) enable the framework to be adapted and extended to fit varying needs, and to be successfully composed with other frameworks. A framework is usually not a complete application: it often lacks the necessary application-specific functionality. Instead, an application may be constructed from one or more frameworks by inserting this missing functionality into the plug-and-play "outlets" provided by the frameworks. Thus, a framework supplies the infrastructure and mechanisms that execute a policy for interaction between abstract components with open implementations.

A definition of an object-oriented software framework is given in [GoF]:

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 sub classing and composing instances of framework classes. ... [a framework] dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately.

The [GoF] book describes the major differences between design patterns and frameworks as follows:

1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly. In contrast, design patterns have to be implemented each time they are used. Design patterns also explain the intent, trade-offs, and consequences of a design.

2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns but the reverse is never true.

3. Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. In contrast, design patterns can be used in nearly any kind of application. While more specialized design patterns are certainly possible, even these wouldn't dictate an application architecture.

[ The information provided above is partially or fully obtained from this book, which is reproduced here for reference only. ]

[ Back to Knowledge base ]