the growing heterogeneity of hardware architectures and diversity of operating system and communication platforms makes it hard to build correct, portable,
efficient, and inexpensive applications from scratch.
1. Library VS framework
Frameworks are active and exhibit ``inversion of control'' at run-time -- Class libraries are typically passive, i.e., they perform their processing by borrowing threads of control from self-directed application objects. In contrast, frameworks are active, i.e., they control the flow of control within an application via event dispatching patterns like Reactor and Observer. The ``inversion of control'' in the run-time architecture of a framework is often referred to as The Hollywood
Principle, i.e., ``Don't call us, we'll call you.''
2. IOC: key of framework
Inversion of control -- The run-time architecture of a framework is characterized by an ``inversion of control.'' This architecture enables canonical application processing steps to be customized by event handler objects that are invoked via the framework's reactive dispatching mechanism. When events occur, the framework's dispatcher reacts by invoking hook methods on preregistered handler objects, which perform application-specific processing on the events. Inversion of control allows the framework (rather than each application) to determine which set of application-specific methods to invoke in response to
external events (such as window messages arriving from end-users or packets arriving on communication ports).
3. Whitebox/blackbox framework
Regardless of their scope, frameworks can also be classified by the techniques used to extend them, which range along a continuum from whitebox frameworks to blackbox frameworks. Whitebox frameworks rely heavily on OO language features like inheritance and dynamic binding to achieve extensibilty. Existing functionality is reused and extended by (1) inheriting from framework base classes and (2) overriding pre-defined hook methods using patterns like Template Method [Gamma:95]. Blackbox frameworks support extensibility by defining interfaces for components that can be plugged into the framework via object composition. Existing functionality is reused by (1) defining components that conform to a particular interface and (2) integrating these components into the framework using patterns like Strategy [Gamma:95] and Functor.
Whitebox frameworks require application developers to have intimate knowledge of the frameworks' internal structure. Although whitebox frameworks are widely used, they tend to produce systems that are tightly coupled to the specific details of the framework's inheritance hierarchies. In contrast, blackbox frameworks are structured using object composition and delegation more than inheritance. As a result, blackbox frameworks are generally easier to use and extend than whitebox frameworks. However, blackbox frameworks are more difficult to develop since they require framework developers to define interfaces and hooks that anticipate a wider range of potential use-cases.
4. Object-oriented Programming and Design:People think concretely, not abstractly. Abstractions are found bottom-up, by examining concrete examples.
5. framework developer OR domain expert?
6. The framework works with little or no client code, even if the default implementations are simply placeholders, and it supports small, incremental steps to get from the default behavior to sophisticated solutions.
7. Over the lifetime of a framework, the cost of supporting it actually becomes a benefit--the support cost of one framework with three dependent applications will be less than the cost of supporting three independent applications with duplicate code.
The more applications that use a framework, the bigger the savings. Long term, using frameworks can reduce support and maintenance costs.
Early in its life, a framework will probably require routine maintenance to fix bugs and respond to client requests. Over time, even the best framework will probably need to be updated to support changing requirements.
8. Good designers know many design patterns and techniques that they know lead to good designs. Applying recurring patterns to the design of a
framework is one form of reuse. Using formalized "design patterns" also helps to document the framework, making it easier for clients to understand, use, and extend the framework.