LARA

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
inheritance [2008/02/04 16:28]
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.