Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
inheritance [2008/02/04 16:25] ersoy |
inheritance [2008/02/04 16:28] ersoy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== A Guide To Inheritance in Programming Languages ====== | ====== A Guide To Inheritance in Programming Languages ====== | ||
| - | Inheritance is one of the core features of Object Oriented programming, which provides reusability and extensiblity. The use of inheritance is often debated among programmers, computer scientists, and language designers. Some claim it should be mostly avoided, and others - generally the functional programming community - go beyond it and advocate that it is simply a bad idea. One of the most common objections is pointed out in the module system section of [3]: "That’s why inheritance in class-based languages is a bad idea. If a class D inherits from a class C, you have an implementation dependency of C on D. This is called the //fragile base class problem//, because changes to C force reconsideration of D." Although that is a valid criticism, the use of inheritance can be justified by the module systems' very limited support for code reuse. Leaving aside that discussion, the main topic of this essay is when and how to use inheritance. Obviously, inheritance can not be used arbitrarily, and not all the class hierarchies make sense. For instance, Palsberg and Schwartzbach [7] defined a //well-formedness// criterion for the use of inheritance, based on IS-A and HAS-A relations. Intuitively the relation A IS-A B holds whenever A is a subclass of B, and A HAS-A B holds whenever B-object is a constituent part of an A-object. A class graph, has nodes as classes and directed IS-A and HAS-A edges between them. A class hierarchy is well-formed, if and only if no directed cycle contains an IS-A edge in its corresponding class graph. | + | Inheritance is one of the core features of Object Oriented programming, which provides reusability and extensiblity. The use of inheritance is often debated among programmers, computer scientists, and language designers. Some claim it should be mostly avoided, and others - generally the functional programming community - go beyond it and advocate that it is simply a bad idea. One of the most common objections is pointed out in the module system section of [4]: "That’s why inheritance in class-based languages is a bad idea. If a class D inherits from a class C, you have an implementation dependency of C on D. This is called the //fragile base class problem//, because changes to C force reconsideration of D." Although that is a valid criticism, the use of inheritance can be justified by the module systems' very limited support for code reuse. Leaving aside that discussion, the main topic of this essay is when and how to use inheritance. Obviously, inheritance can not be used arbitrarily, and not all the class hierarchies make sense. For instance, Palsberg and Schwartzbach [8] defined a //well-formedness// criterion for the use of inheritance, based on IS-A and HAS-A relations. Intuitively the relation A IS-A B holds whenever A is a subclass of B, and A HAS-A B holds whenever B-object is a constituent part of an A-object. A class graph, has nodes as classes and directed IS-A and HAS-A edges between them. A class hierarchy is well-formed, if and only if no directed cycle contains an IS-A edge in its corresponding class graph. |
| Inheritance is not subtyping [1], but I will focus on subclassing that creates subclasses, and I will handle the useful exceptional cases (e.g. implementation inheritance) explicitly by providing some static guarantees. | Inheritance is not subtyping [1], but I will focus on subclassing that creates subclasses, and I will handle the useful exceptional cases (e.g. implementation inheritance) explicitly by providing some static guarantees. | ||
| Line 32: | Line 32: | ||
| 2) Convenience Inheritance: This is using inheritance just for resusing some features. Meyer says, convenience inheritance is unacceptable; however, implementation inheritance is a form of convenience inheritance. Instead of changing the definition of "is-a" into something different, just to allow some forms of inheritance for convenience, I will propose a more general approach. The principle is ensuring safety when one class does not subsume the other. For instance, in the presence of implementation inheritance, Meyer proposes hiding the inherited methods using Eiffel's facilities. C++ has a private inheritance mechanism that can be used for the same purpose. However, some languages like Java do not have such facilities. For any kind of convenience inheritance, static safety mechanisms should be developed. | 2) Convenience Inheritance: This is using inheritance just for resusing some features. Meyer says, convenience inheritance is unacceptable; however, implementation inheritance is a form of convenience inheritance. Instead of changing the definition of "is-a" into something different, just to allow some forms of inheritance for convenience, I will propose a more general approach. The principle is ensuring safety when one class does not subsume the other. For instance, in the presence of implementation inheritance, Meyer proposes hiding the inherited methods using Eiffel's facilities. C++ has a private inheritance mechanism that can be used for the same purpose. However, some languages like Java do not have such facilities. For any kind of convenience inheritance, static safety mechanisms should be developed. | ||
| + | |||
| =====References===== | =====References===== | ||
| Line 39: | Line 40: | ||
| [2] Nicola Guarino, Christopher Welty. Evaluating ontological decisions with OntoClean. //Communications of the ACM//, v.45 n.2, February 2002. | [2] Nicola Guarino, Christopher Welty. Evaluating ontological decisions with OntoClean. //Communications of the ACM//, v.45 n.2, February 2002. | ||
| - | [3] Robert Harper. //Programming in Standard ML//. Draft, 2005. Available at: http://www.cs.cmu.edu/~rwh/smlbook/ | + | [3] Nicola Guarino, Christopher Welty. An overview of OntoClean. In S. Staab and R. Studer, editors, //Handbook on Ontologies//. Springer Verlag, 2003. |
| + | |||
| + | [4] Robert Harper. //Programming in Standard ML//. Draft, 2005. Available at: http://www.cs.cmu.edu/~rwh/smlbook/ | ||
| - | [4] Gary T. Leavens, David A. Naumann. Behavioral subtyping, specification inheritance, and modular reasoning. Technical Report 06-20a, Department of Computer Science, Iowa State University, Ames, Iowa, 50011, Aug. 2006. | + | [5] Gary T. Leavens, David A. Naumann. Behavioral subtyping, specification inheritance, and modular reasoning. Technical Report 06-20a, Department of Computer Science, Iowa State University, Ames, Iowa, 50011, Aug. 2006. |
| - | [5] Barbara Liskov, Jeanette M. Wing. A behavioral notion of subtyping. //ACM Transactions on Programming Languages and Systems//, 16(6), 1994. | + | [6] Barbara Liskov, Jeanette M. Wing. A behavioral notion of subtyping. //ACM Transactions on Programming Languages and Systems//, 16(6), 1994. |
| - | [6] Bertrand Meyer. //Object-oriented software construction// (2nd ed.). Prentice-Hall, Inc., Upper Saddle River, NJ, 1997. | + | [7] Bertrand Meyer. //Object-oriented software construction// (2nd ed.). Prentice-Hall, Inc., Upper Saddle River, NJ, 1997. |
| - | [7] Jens Palsberg, Michael I. Schwartzbach. //Object-oriented type systems//. John Wiley and Sons Ltd., Chichester, UK, 1994. | + | [8] Jens Palsberg, Michael I. Schwartzbach. //Object-oriented type systems//. John Wiley and Sons Ltd., Chichester, UK, 1994. |
| - | [8] Christopher Welty, Nicola Guarino. Supporting ontological analysis of taxonomic relationships. //Data & Knowledge Engineering//, v.39 n.1, p.51-74, October 2001. | + | [9] Christopher Welty, Nicola Guarino. Supporting ontological analysis of taxonomic relationships. //Data & Knowledge Engineering//, v.39 n.1, p.51-74, October 2001. |