Dissection of an Application Frameworks
After the framework design is done, the next phase is to actually code the application framework. The implementation phase has one goal, which is to develop a framework that meets the requirements and time constraints. If you have done a good design job on the framework, implementing it is no different from regular application development. As with application development, where different team members can work on different parts of the same application simultaneously, you can have work progressing on different pieces of the application framework simultaneously, as long as the framework is partitioned into well-defined modules. Unit testing on the newly created functionality can be tricky during framework development. In the case of application development, developers will simply test the use case on the newly created functionality to see whether it works as desired. However, unit testing of frameworks is much less direct and visual than that of business applications, since the application that uses the framework simply hasn't been created yet and all the business data needed by the application have not been generated.
As with application development, you can create number of milestone releases during the implementation phase. You can create several incremental releases so that you can get part of the application framework to developers and start getting feedback on any potential improvements and fixes for the next release.
Testing the framework in this phase is often driven by developers instead of professional quality-assurance testers or business end users, since developers are the primary users of the framework. During the stabilization phase of the framework development, the design and construction of the actual application have not yet started, so developers haven't yet created much application code. In such a situation, you need to identity at least one usage scenario in the business application for each framework component and service and ask the development team to write a small portion of the application based on such usage scenarios. Although it is not possible to test every framework usage scenario of an application that has not yet been built, you can effectively test your framework through the selective implementation of part of a business application that is representative of the usage pattern of the framework.
Of course, in order for developers to develop part of an application based on the framework, they must know how to use the framework productively. As the creator of the application framework, you will initiate developer training in the stabilization phase. The better job you do educating developers about the framework, the better the developers will be able to test your framework and the more productive they will be when they start using your framework extensively in application development.
Besides conducting frequent training sessions on how to use the application framework, you also need to produce good documentation of your framework, which will be an invaluable tool in helping developers learn to use the framework.
Typical documentation created to help developers consists of four parts:
- An overview of the framework that explains the purpose of the framework and the major components and services available in the framework.
- Some pictures, diagrams, and descriptions of the framework that help developers grasp the framework and its design philosophy.
- An API reference for the functionalities inside the framework that enables developers to look up the framework's functionalities during the development process.
- A collection of examples that show how the framework is used. Concrete examples of the framework in action best demonstrate the usage scenario of the application framework and help shorten the learning process for developers.
The stabilization phase is also where the framework designer will continually collect developers' feedback on the framework for the next iteration of framework development. After developers start using the framework, the framework designer must also participate in the effort of application development by providing assistance to the developer team, answering questions and solving problems related to the usability of the framework.
With a development process in place for framework development, let's look at some common approaches and techniques for developing a framework that we will use in the rest of the book.
Framework Development Techniques
In order to develop an effective application framework, you need to know some common techniques for framework development. The following list shows some useful techniques and approaches that can help you develop a framework that is both easy to use and extensible.
- Common spots
- Hot spots
- Black-box framework
- White-box framework
- Gray-box framework
- Design patterns
Common spots, hot spots, and design patterns are some of the techniques used in framework development. Black, white, and gray boxes represent the approaches you can take to developing the framework.
Common spots, as the name suggests, represent the places in the business application where a common theme is repeated over and over again. If certain parts of the application repeat without much variation throughout the application, we can extract such common spots out of the application and package them into components in the framework layer. By moving such common spots into the framework, you avoid the duplication of such common spots throughout the application, and hence promote code reuse. This reduces the development effort when developers can simply referencing to the common spot in the framework from their applications. Figure 3 shows how the common spots relate to the framework and business application.
Figure 3. Common spots
In Figure 3, the application framework contains the components that provide the implementation for various common spots found in the application. When developers start building applications, they will reference the common spots implemented in the framework component instead of developing them themselves. As a result, the amount of application code they have to write is reduced.
To qualify as a common spot, a theme does not have appear in exactly the same way throughout the application. As long as the variations are small, you can still treat them as common spots and handle the small variations through parameterization and/or configuration settings.
Page 3 of 4