You want to use the framework to solve a specific problem. You need to know how the framework can be used to implement a specific solution to that problem.
To effectively use a framework, its flexibility and reuse points reside mostly at an intermediate design level. Due to its complexity, it is not clear where those points are and how they are used to implement the solution. Therefore, understanding the design internals is essential to find those flexibility points.
How do you understand the design internals of a framework?
Design complexity. A framework design is, by nature, complex. Most of its complexity can be found at this level of design.
Inheritance vs. composition. Design variations for the same problem may prove to be a hinder because they obfuscate the identification of existing solutions as they seem dissimilar.
Documentation. Depending on the existing documentation, one may find bits and pieces of information about how design solutions were implemented to solve specific domain problems.
Tools. Reverse engineering and software visualization tools that aid in identifying known design structures and patterns may save time and give a different view over the whole or part of the framework’s design.
Go through the DESIGN INTERNALS documentation, or browse the existing classes, and identify the concept classes and their interactions.
Look for instances of known design patterns. Design patterns [GHJV94] are often used as building blocks for frameworks, because they introduce the flexibility it needs. The more mature a framework is, the more design patterns will it encompass. Design patterns aggregate these “hot spots” or CUSTOMIZATION POINTS: areas of flexibility we can “hook” [FHL97] into and take full advantage of the framework’s reusability.
Preserve all the information gathered, adopting a KNOWLEDGE KEEPING strategy.
Framework internal mechanisms. You gain knowledge about how the framework provides the flexibility for adapting its semi-implementation to develop an application. You acquired most of the information to adapt the framework to your needs.
Still at a Design level. Understanding is kept at a design level. Adapting means implementing, and implementing means coding. You need therefore to UNDERSTAND THE SOURCE CODE .
Frameworks are designed and implemented to fully exploit the use of dynamically bound methods. Template and hook methods [Pre95][GHJV94] are two kinds of methods extensively used in the implementation of frameworks, to provide it with its flexibility and adaptability.
Generally, template methods are used to implement the frozen spots of a framework, and hook methods are used to implement the hot spots. The frozen spots are aspects that are invariant along several applications in a domain, possibly representing abstract behavior, generic flow of control, or common object relationships. The hot spots of a framework are aspects of a domain that vary among applications and thus must be kept flexible and customizable.
The difficulty of good framework design resides exactly on the identification of the appropriate hot spots that provide the best level of flexibility required by framework users. More hot spots offers more flexibility, but results in a framework more difficult to design and use, so somewhere in between resides a balanced design.
In [Pre95] are identified several ways of composing template and hook classes, and presented under the form of a set of patterns, globally called meta-patterns. Meta- patterns categorize and describe the essential constructs of a framework, on a meta-level. Design patterns provide proven solutions to recurrent design problems and are extremely useful to design object-oriented frameworks. The motivation for using meta-patterns is to provide a means to categorize and describe design patterns on a meta-level, and to support framework construction. Therefore, design patterns become the building blocks of frameworks.
Design patterns can be used as inspiration when looking for flexible hot-spots within a framework. A framework that contains design patterns can be understood in term of these; therefore when adapting a framework, users can perceive the specific adaptation steps (sub-classing or configuring framework classes) as adaptations of small wholes – the involved design patterns – instead of making new atoms (classes). Users see their adaptations in a perspective larger than that of a single class [JN99].
In [BSM06], Bruch et al. propose the use of data mining techniques to extract reuse patterns from existing framework instantiations. Based on these patterns, suggestions about other relevant parts of the framework are presented to novice users in a context-dependent manner.
In [FGS06], Fairbanks et al. present a pattern language based on the notion of design fragment. A design fragment is a pattern that encodes a conventional solution to how a programmer interacts with a framework to accomplish a certain goal. It provides the programmer with a “smart flashlight” to help him/her understand the framework, illuminating only those parts of the framework he/she needs to understand for the task at hand. Design fragments give programmers immediate benefit through tool-based conformance and long-term benefit through expression of design intent.