Don't burn your base class
(New page: This is a comment on the use of inheritance, and is especially applicable to object-oriented programming languages that employ a single inheritance model. ==Have I burned my base class?==...) |
WarwickIrwin (Talk | contribs) m |
||
| (5 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
This is a comment on the use of inheritance, and is especially applicable to object-oriented programming languages that employ a single inheritance model. | This is a comment on the use of inheritance, and is especially applicable to object-oriented programming languages that employ a single inheritance model. | ||
| − | + | A designer has "burned" their base class when they have, perhaps unnecessarily, used inheritance to access the attributes and/or behaviours of another class. In a single inheritance model, they have consumed or "burned" their one chance to inherit. | |
| − | + | It is often not obvious that a designer has "burned" their base class until a more appropriate use for inheritance is discovered. In this situation it may be beneficial to replace the original use of inheritance, so that inheritance may be used where it is most necessary. Obviously, this is not usually such an issue in multiple inheritance models. However, unnecessary use of inheritance still has negative effects such as increased rigidity. | |
| − | + | If a designer has “burned” their base class, it may be inferred that the designer has misused the inheritance model. This can be the case where the inheritance relationship does not represent a specialisation of the base class, or does not take advantage of polymorphism. | |
| − | + | In some cases, a designer can force a client to "burn" their base class by providing access to functionality or behaviours via inheritance only. This will then limit how the client can make use of inheritance in their own design. This happens for example when implementing the [[Observer]] design pattern in Java. The subject part of the pattern inherits from java.util.Observable to get the behavior for notifying observers. However, in this way it has burned its chance to inherit from another class which may be a more appropriate superclass. | |
| − | == | + | ==Refactor With== |
| + | *[[Replace Inheritance with Delegation]] | ||
| − | + | ==See Also== | |
| + | *[[Avoid inheritance for implementation]] | ||
| + | *http://www.artima.com/intv/dotnet.html (Only reference I can find...) | ||
Latest revision as of 04:13, 2 February 2011
This is a comment on the use of inheritance, and is especially applicable to object-oriented programming languages that employ a single inheritance model.
A designer has "burned" their base class when they have, perhaps unnecessarily, used inheritance to access the attributes and/or behaviours of another class. In a single inheritance model, they have consumed or "burned" their one chance to inherit.
It is often not obvious that a designer has "burned" their base class until a more appropriate use for inheritance is discovered. In this situation it may be beneficial to replace the original use of inheritance, so that inheritance may be used where it is most necessary. Obviously, this is not usually such an issue in multiple inheritance models. However, unnecessary use of inheritance still has negative effects such as increased rigidity.
If a designer has “burned” their base class, it may be inferred that the designer has misused the inheritance model. This can be the case where the inheritance relationship does not represent a specialisation of the base class, or does not take advantage of polymorphism.
In some cases, a designer can force a client to "burn" their base class by providing access to functionality or behaviours via inheritance only. This will then limit how the client can make use of inheritance in their own design. This happens for example when implementing the Observer design pattern in Java. The subject part of the pattern inherits from java.util.Observable to get the behavior for notifying observers. However, in this way it has burned its chance to inherit from another class which may be a more appropriate superclass.
Refactor With
See Also
- Avoid inheritance for implementation
- http://www.artima.com/intv/dotnet.html (Only reference I can find...)
