On the Development of Object-Oriented Frameworks
This essay was presented at the OOPSLA'96 Conference workshop on Software Frameworks.
After nearly three years of programming in Smalltalk, I have decidedly mixed feelings about frameworks. The ones I've created have been a great help to me, but using the frameworks created by other people was mostly an exercise in frustration. I suspect a lot of programmers feel the same way. So what is the problem with frameworks, and what can be done about it?
A framework is a set of classes and objects that provide a context for the implementation of some aspect of one or more applications. It provides the applications with a set of services, and sometimes with reusable components designed for the framework.
If the framework is broad enough and general enough, a good framework also has the beneficial effect of standardizing applications, and make it easier to create and maintain them. Programmers can take advantage of the services and components provided by the framework and need to learn only one way to do whatever the framework supports; alternatives need not be considered. The framework raises the level of abstraction at which the programmer works, and thereby reduces both effort and cost.
However, creating a framework with these characteristics is not an easy (or cheap) thing to do. It often takes multiple iterations to even begin to understand what is needed and possible. As additional applications are created in the framework, new requirements manifest themselves, leading to either evolution or devolution, depending on the amount of care given to the creation and maintenance of the framework.
If the frameworks of a project are to be used in multiple applications, substantial investments may be required in their creation and maintenance. However, some frameworks are actually accidental constructs resulting from inheritance hierarchies created primarily to reduce code duplication, and are not recognized as frameworks at all. And other frameworks are initially created to accomplish specific tasks, without any concern for their reuse. In either case are they viewed as being secondary in importance to the real application code.
One of the keys to successful framework development, therefore, is to recognize when a framework is being created, identify it in the project plan as a framework, and decide on an appropriate level of investment. This recognition can occur during the analysis and design phase of the project, but it may also occur later, during development. In either case, project management needs to become specifically aware of all new frameworks so that appropriate investment decisions can be made. One possible decision, of course, is to not develop the framework, to look for commercially available alternatives instead.
An important area of investment in frameworks is in their documentation. More attention must be paid to the documentation of a framework, not less. Too often, only the original programmer of a framework knows what it was actually designed to do or how to use it. It is not enough to assume that subsequent programmers, who need to either use or extend the framework, can just read the code. This is a waste of everyone's time and talents, the sign of an immature hacker, and shows a selfish lack of consideration for team mates.
At a minimum, as with all programming, the code of a framework should be created with careful attention to class, variable and method names, and with comments to explain what problems are being solved and why the code is structured as it is. But this is not enough documentation for frameworks. Specific attention must be paid to the needs of the programmers who will build applications within the framework and possibly extend it.
To the extent possible, this extra documentation should be incorporated into the on-line documentation of the code, in the form of package and class comments. But even this may not be enough for complex frameworks, particularly because code editors and browsers typically do not have adequate facilities for formatting text and illustrating concepts with drawings. If necessary, use a full-featured word processor, and make the resulting document available on-line.
The following is the outline of a document that describes a framework (with a lot of supporting figures):
- What programming problem is solved by the framework.
- General description of the framework.
- A simple example of the use of the framework.
- Programming patterns used by the framework.
- Major components of the framework.
- Relation of the framework to other major system components and frameworks.
- Types of components that fit into the framework.
- Framework Operation
- Life cycle of the framework (i.e., starting, operating, terminating).
- Life cycle of the components in the framework (i.e., creation, activation, initialization, operation, termination).
- Between the framework and its components.
- Between components.
- Between components and other instances of the framework.
- How to create components within the framework.
- How to extend the framework.
- How to create new classes of components.
- Component Descriptions (for each component accepted in the component library)
- User interface requirements.
- Subcomponents, required or optional.
- Object model aspect requirements.
- Properties of the component.
- Events triggered by the component.
- Common Component Patterns
Patterns of components, discovered in the initial project to be useful in solving particular problems, are described using the method and topics pioneered in Design Patterns: Elements of Reusable Object-Oriented Software. An extended example is provided for each pattern. Programmers find these patterns to be invaluable in understanding the overall framework and its application.
Considerable effort is required to document a framework in this way, but programmers can more easily learn and use both the framework and its components. A result is the increased level of reuse that gives Object-Oriented Technology its great pay back. Another result is additional requirements for new levels of support from the framework and for new components; that is, for their continued evolution.
As a result of writing this workshop paper, I came to realize that the framework documentation it prescribes could be easily provided using a design pattern -- the framework providing the syntax and grammar of a pattern language, and the plug-in components its vocabulary.
E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
Sur l'élaboration des structures de objet-orientation
Désolé, pas encore traduit.