Johnson and Foote 1988
m (Reverted edits by Ebybymic (Talk); changed back to last version by Linda Pettigrew) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 6: | Line 6: | ||
== Contribution == | == Contribution == | ||
| − | A set of design techniques which makes | + | A set of design techniques which makes OO software more reusable are described in this paper. The features of OO languages which make reuse simpler and more attainable are also discussed. |
== Analysis == | == Analysis == | ||
| − | This early paper has been very influential. | + | This early paper has been very influential. The paper uses Smalltalk examples and terminology to relate ideas about the development of object oriented software. |
| − | + | The paper is the original paper to [[Favor composition over inheritance]]. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | === OOD heuristics === | ||
| + | A section of the paper outlines a thirteen rules for designing OO software. The rules are presented concisely with a description and example of where they are applicable. See [[Design maxims]] and [[Johnson and Foote's heuristics]] for a comprehensive description. | ||
=== White box and black box reuse === | === White box and black box reuse === | ||
| Line 30: | Line 28: | ||
With white box reuse we inherit all implementation details from the super class. This means the programmer must be aware of all these details. Black box reuse only requires the programmer to understand the protocol defined by the public interface of that class. | With white box reuse we inherit all implementation details from the super class. This means the programmer must be aware of all these details. Black box reuse only requires the programmer to understand the protocol defined by the public interface of that class. | ||
| − | In general, black box reuse is easier but less flexible than white box reuse. As the design is improved, white box reuse should be substituted for black box reuse. | + | In general, black box reuse is easier but less flexible than white box reuse. As the design is improved, white box reuse should be substituted for black box reuse. It is noted that a framework is likely to go through a stage of being a white box before the necessary abstractions are made to make the framework a black box. |
In terms of statically typed languages like Java: | In terms of statically typed languages like Java: | ||
Latest revision as of 03:22, 25 November 2010
Designing reusable classes , by RalphJohnson & BrianFoote, Journal of Object-Oriented Programming, June/July 1988, Volume 1, Number 2, pages 22-35.
The text is available from the links below.
Contents |
Contribution
A set of design techniques which makes OO software more reusable are described in this paper. The features of OO languages which make reuse simpler and more attainable are also discussed.
Analysis
This early paper has been very influential. The paper uses Smalltalk examples and terminology to relate ideas about the development of object oriented software.
The paper is the original paper to Favor composition over inheritance.
OOD heuristics
A section of the paper outlines a thirteen rules for designing OO software. The rules are presented concisely with a description and example of where they are applicable. See Design maxims and Johnson and Foote's heuristics for a comprehensive description.
White box and black box reuse
One of the central themes of this paper is that there are two main ways of designing classes for reuse:
- White box reuse, in which new classes should reuse existing classes by inheriting from them.
- Black box reuse, in which new classes should reuse existing classes by composing them.
Black box reuse is preferred to white box, because the classes are less exposed to each other (i.e. they have weaker coupling). However, white box reuse is still recognised as a valuable technique.
With white box reuse we inherit all implementation details from the super class. This means the programmer must be aware of all these details. Black box reuse only requires the programmer to understand the protocol defined by the public interface of that class.
In general, black box reuse is easier but less flexible than white box reuse. As the design is improved, white box reuse should be substituted for black box reuse. It is noted that a framework is likely to go through a stage of being a white box before the necessary abstractions are made to make the framework a black box.
In terms of statically typed languages like Java:
- Black box reuse allows use only of the public interface of a server class;
- White box reuse allows use of both the public and protected interfaces of the server class.
