Dissection of an Application Frameworks, Part 2
A white-box framework is a framework that consists of abstract classes. Adapting a white-box framework requires developers to create concrete classes that inherit the abstract classes in the framework. White-box frameworks take on the inheritance approach to enable their hot spots. Figure 7 shows a white-box framework.
A white-box framework is relatively easy to develop. You can start developing the abstract class by looking at some of the similar applications you have developed before, identifying their hot spots, and making them the abstract methods. When developing white-box frameworks, you are making an assumption about the pattern of process flow involved in each framework component through the template method. You often base these assumptions on business-domain expertise and prior business-application development experience. As developers start adapting the white-box framework, they need to program only a small number of "override" methods in the derived class and don't have to worry about the overall process flow or how the abstract method is used inside the framework. This allows developers to focus solely on the abstract method without worrying about how the methods they are overriding relate to the rest of the framework.
Of course, there is a tradeoff in almost everything. White-box frameworks are very easy to design and develop, but they have their drawbacks. The first drawback is their inflexibility. In a white-box framework, when you determine how the process flow occurs inside a component through the template method you effectively hard-code the process flow and coordination logic in the component. Although developers who adapt the component may change the logic of the component's hot spot, the overall process flow is nevertheless fixed. This "hard-coded" process flow is reflected as inflexibility when a change in business rules triggers a change in the process flow in the component. Because the process flow and coordination logic are fixed, you would have to update the existing component or write a new one that carries the process flow and coordination logic.
Another drawback of a white-box framework is that it often requires the developer to know many implementation details of the framework component. As the developer is implementing the abstract method in the framework component, he or she often needs to reference the abstract class's methods and variables in the implementation code. This makes the understanding of internal details of the framework component an important prerequisite for correctly adapting the component.
A black-box framework often takes a composition-style approach to solving some of the challenges of the white box, but it has its own share of drawbacks.
Black-box frameworks consist of concrete and ready-to-use classes and services. Although developers can extend the existing framework components to achieve customization in a black-box framework, they more often adapt the framework by combining a number of components to create the desired result. A black-box framework may contain many common spots, and it employs the composition approach to enable its hot spots. Figure 8 illustrates a black-box framework.
Figure 8. A black-box framework
Because of the composition approach in a black-box framework, it provides a greater range of flexibility than that of a white-box framework. Developers can pick and choose different components to achieve specific application requirements with infinite possibilities. Unlike white-box frameworks, where a developer often needs to know the detailed implementation of the framework component for adaptation, black-box frameworks consist of components that hide their internal implementation. Adaptation of such components is done through well-defined interfaces, such as certain public methods and properties. Developers need to be familiar with only these public members in order to use the framework.
Compared with white-box frameworks, black-box frameworks are harder to develop. Encapsulating business-domain expertise into components that are generic enough to be used in many application scenarios is not an easy task. Encapsulating too much will lead the domain expertise inside the component becoming less fit in many application scenarios. Encapsulating too little will lead to developers having to work with a large number of components and more complex coordination logic in order to build the application.
The extra flexibility of black-box frameworks doesn't come for free. When using a black-box framework, developers must implement their own process flow and coordination logic needed to link multiple components together. Because developers now control how and what components need to work together, they are responsible for the extra workload on "wiring" the components together along with the extra flexibility provided by the black-box framework. In contrast, white-box frameworks automatically handle the "wiring" for you in the template methods of their components.
Although developers don't have to deal with learning the internal implementation of the abstract class as they do with a white-box framework, they do have to be familiar with a greater number of components and their use when using a black-box framework, since the developer now has more "moving" parts to deal with in order to combine them into something they need.
When developing an application framework, there is no requirement that the framework contain either all abstract classes or all concrete classes. In fact, neither pure white-box nor black-box frameworks are practical in the real world. Having a mix of both the inheritance approach and composition approach gives you the freedom to use whatever approach is best for the design of a particular component. By mixing white-box frameworks and black-box frameworks, you effectivelycreate a gray-box framework.
Page 3 of 4