| || |
Developing a Framework
| You Are Here: Home > Developing a Framework |
The first step in developing a framework is to analyze your problem domain and identify the frameworks you need. For each framework, you:
o Identify the framework components and primary abstractions.
o Design how clients interact with the framework
o Implement, test, and refine the design
Analyzing the Problem Domain
Once you've identified the problem domain, break the problem down into a collection of framework components that can be used to build a solution.
If the problem maps to a process, describe the process from the user's perspective. For each framework, identify the process it models. Once you've outlined the process, you should be able to identify the necessary abstractions.
Components can be thought of as abstractions of possible solutions to problems. You can often identify opportunities for new components by analyzing existing solutions.
o Look for software solutions that you build repeatedly, particularly in key business areas
o Identify what the solutions have in common and what is unique to each program
The common pieces--the parts that are constant across programs--become the foundation for your framework. Factor these pieces into small, focused components.
The easiest way to identify the abstractions is with a bottom-up approach--start by examining existing solutions. Analyze the data structures and algorithms and then organize the abstractions. Always identify the objects before you map out the class hierarchy and dependencies.
If you are familiar with the problem domain, you can draw from your past experience and former designs to identify abstractions and begin designing your framework.
Examine applications written by others and consider writing an application in the domain. Then factor out the common pieces and identify the abstractions.
Look for ways to reduce the amount of code that clients must write:
o Provide concrete implementations that can be used directly
o Minimize the number of classes that must be derived
o Minimize the number of member functions that must be overridden
One of the things to consider is how to support customization. Customization is a two-edged sword--you want to provide as flexible framework as possible, but you also want to maintain the focus of the framework and minimize the complexity for the client.
One approach is to build a very flexible, general framework from which you derive extended frameworks for narrower problem domains. These additional framework components provide the default behavior and built-in functionality, while the general framework provides the flexibility.
As you design the framework, also consider how the design can help communicate how to use the framework. Class names, functions names, and how you use pure virtual functions can all provide cues for using the framework.
You also need to determine how the framework classes and member functions interact with client code:
o What objects are created when the client calls framework functions?
o When the framework calls client overrides?
Guidelines for generalizing a design:
o Consolidate similar functionality across the system and implement it through a common abstraction.
o Divide large abstractions into several smaller abstractions. Each of the smaller abstractions should have a small, focused set of responsibilities.
o Implement each variation of an abstraction as an object. This increases the flexibility of the design.
o Use composition instead of inheritance where possible. This reduces the number of classes and reduces the complexity for the framework client.
Building a framework is an iterative process.
Code comments and documentation are a necessary part of any programming project, but they are especially important when you're developing frameworks. If other developers don't understand your framework, they won't use it.
Developers are interested in solving particular problems - the details of the framework implementation are not important.
It is best to provide a variety of documentation:
o Sample programs
o Diagrams of the framework architecture
o Descriptions of the framework
o Descriptions of how to use the framework
As a general rule, you should:
o Fix bugs immediately
o Add new features occasionally
o Change interfaces as infrequently as possible
It's better to add new classes instead of changing the existing class hierarchy, or to add new functions instead of changing or removing existing functions.
Developing Framework Components
When you develop components:
o Derive components from existing problems and solutions
o Develop small focused components
o Build components using an iterative process driven by client participation and prototyping
o Treat components as products - provide documentation and support and plan for distribution and maintenance
When you begin to develop a component, you make many small iterations on the design and initial implementation. As the framework matures and your clients begin to rely on it, the changes become less frequent and you move into a much larger maintenance cycle. You can divide this process into four general tasks:
Identify and characterize the problem domain
o Outline the process
o Examine existing solutions
o Identify key abstractions
o Identify what parts of the process the component will perform
o Solicit input from clients and refine your approach
Define the architecture and design
o Focus on how clients interact with the components:
o What classes does the client instantiate?
o What classes does the client derive?
o What functions does the client call?
o Apply recurring design patterns
o Solicit input from clients and refine your approach
Implement the component
o Implement the core classes
o Test the component
o Iterate to refine the design and add features
Deploy the component
o Provide documentation in the form of diagrams, recipes, and especially sample programs
o Establish a process for distribution
o Provide technical support for clients
o Maintain and update the component
|©2002 Frontior Technologies. All Rights Reserved.