Principles for Developing Application Frameworks

Simplicity

Simplicity refers to the way the framework simplifies development by encapsulating much of the control of process flow and hiding it from the developers. Such encapsulation also represents one of the distinctions between a framework and a class library. A class library consists of a number of ready-to-use components that the application developers can use to build an application. However, the application developers must understand the relationships between various components and write process flow code to wire many components together in the application. On the other hand, a framework encapsulates the control of such process flow by prewiring many of its components so that the application developers do not have to write code to control how the various components interact with each other. The following figure illustrates the difference between a class library and a framework.

By moving the process flow logic from the application to the application framework, the framework designer can use his or her architecture and domain expertise to define how components should work together inside the framework. As a application developer starts using the framework, he or she can be highly productive in developing the application knowing very little about how the framework components work together.

Maintainability

Maintainability, the ability to effectively support changes to the application as a result of changes to the business requirements, is a welcome side effect of code reuse. The application framework may also contain many layers. Each layer makes certain assumptions about the business the application is intended to serve. As you move higher up the stack of the layers, its components depend on more business assumptions than do the previous layers, and hence are more susceptible to change when business requirements and rules change. When changes do occur, only the components at the layer where the business assumption is broken need to be fixed and tested. Therefore, by injecting different levels of business knowledge into different levels of the framework layers, you can reduce the cascade effect of changing business rules and requirements to the application. This also leads to the reduction of maintenance costs, since you need to touch only the code that is affected by the business rule change.