CSC/ECE 517 Summer 2008/wiki2 8 jb
This wiki will follow the debate over inheritance vs. delegation, with the goal of showing the strengths and weaknesses of each approach, and where each approach is preferred.
Background
A brief description of Inheritance and Delegation will help get us started:
Inheritance
Inheritance is one of the fundamental tenets of object oriented programming. Inheritance refers to the ability to model hierarchies of classes that are related to each other through the is-a relationship. It is commonly agreed upon that inheritance done correctly must conform to the Liskov substitution principle. Inheritance is closely related to the topics of dynamic binding and polymorphism. Dynamic binding refers to a language's support for virtual methods, allowing the determination of the actual method invoked on a particular object to be determined at runtime. Polymorphism refers to the ability to store a reference to a derived class within a variable declared as a base class type.
Delegation
Delegation, sometimes referred to as aggregation, is the concept that one class may contain an instance of another class, and delegate some responsibility to that class. This is also referred to as the has-a relationship. Aggregation is closely related to composition. Both aggregation and composition are used to describe one object containing another object, but composition implies ownership [1]. Aggregation is more general and doesn't imply any responsibilities for memory management. A class which contains other classes is called a composite class, while a class being contained is called a composited or composed class [2].
Design Pattern: Replace Inheritance with Delegation
Before we discuss the main points of the inheritance vs. delegation debate, it is worthwhile discussing a design pattern that describes how to replace delegation with inheritance. The idea behind the pattern is extremely simple: instead of deriving a new class from an existing class, make your new class contain an instance of the existing class. An example of the pattern being applied is shown below in the graphic. In this case a Stack was implemented as being derived from a Vector. You could imagine that the stack would add the push and pop methods, but use the vector for the actual storage. Instead of deriving the Stack from Vector, the pattern dictates that the Stack should contain an instance of a Vector.
It is useful to discuss this pattern prior to the debate so that you can keep the example of the Stack in mind while thinking about this main points of the debate. The Stack example is simplistic, but nicely shows the equivalence of the two approaches. The major points in the debate assume this equivalence in order to argue their points. After we go over the debate, we will look at some cases where the two approaches are not equivalent in order to show where each approach is preferred.
The Debate
Much of the debate is focussed on arguments against using inheritance. The most notable and widely accepted statement on the subject came from the original GoF, or Gang of Four, in their book titled Design Patterns: Elements of Reusable Object-Oriented Software. The book stated to "Favor object composition over class inheritance" as design principle. This position is backed up by many strong arguments.
Arguments against Inheritance
Inheritance breaks encapsulation
- Critics of inheritance argue that the public and protected access modifiers, when used for attributes, break encapsulation by letting a derived class peer inside of its base class [3]
- The point about breaking encapsulation also comes up when talking specifically about implementation inheritance. Implementation inheritance refers to the practice of inheriting from an actual class as opposed to an interface. The idea behind implementation inheritance is to re-use code from the base class and add or customize some desired behavior. The argument against implementation inheritance is that it breaks encapsulation by making the functionality of the subclass dependent on the implementation of the base class [4]. Interface inheritance, on the other hand, is when a class either derived from a pure virtual class in c++, or implements an interface in Java. Interface inheritance does not break encapsulation, and is the idea behind the GoF's design principle of programming to an interface
Inheritance increases coupling
- Critics of inheritance argue that inheritance can lead to brittle code due to coupling between base and derived classes [5]. When using delegation there is a single, explicit dependency between the composite and composed classes; the interface of the composed class. With inheritance the dependencies become blurred with multiple factors leading to close coupling. Access to base class members, unanticipated consequences of executing virtual methods, etc... all contribute to a more brittle relationship and runtime behavior that can be difficult to predict.
- The coupling introduced by inheritance introduces compile time dependencies that can lead to increased build times. [6]. In C++, the header file containing the base class declaration must be pulled in when compiling a derived class header. There is the obvious penalty of reading the file from disk, but the bigger problem is that the changes high up in a class hierarchy can cause a large number of objects to be rebuilt. This can be contrasted to delegation, where a composited class can be declared with a forward declaration to avoid the compile time penalty.
- http://en.wikipedia.org/wiki/Yo-yo_problem
Inheritance is static and determined at compile time
- In statically typed languages such as c++ and java, the class hierarchy is determined at compile time. Delegation has the advantage in that the composite object can swap out the composed object at runtime. Ruby, a dynamically typed language, avoids this compile time restriction and allows changing a class' inheritance at runtime using run-time mixins.
Multiple inheritance and the diamond problem
- Languages that support multiple inheritance, such as C++, are exposed to the diamond problem. The diamond problem arises when a class derives from two base classes that each have a common ancestor. This leads to several problems, including ambiguous virtual method resolution, and potential duplication of data. Virtual method resolution is problematic since a class experiencing the diamond problem can potentially have multiple virtual method implementations available. This forces the language runtime designer to define a heuristic for picking one, which is essentially an arbitrary determination. Data duplication is also an issue, since a class experiencing the diamond problem will end up with multiple copies of the data fields at the root of the hierarchy.
- Language designers have introduced the concept of virtual inheritance to help programmers avoid the data duplication aspects of the diamond problem. Virtual inheritance works by adding a vftable pointer to each class that inherits virtually from another. This allows the determination of the base class' location to be determined at runtime, but comes with a penalty. Programmers employing virtual inheritance on extremely large object hierarchies have run into memory problems due to carrying these extra vftables [7]
Arguments against delegation
Delegation leads to bloated Code
- The main point used against delegation is that it increases code size[8]. The argument is that when delegation doesn't allow any of the code re-use that inheritance does. Inheritance allows the programmer to only define additional, or specialized functionality within derived classes. Using delegation as a direct replacement for inheritance requires more code, since in order to program to the interface, the entire interface must be supported by the composed object.
- These arguments fail to consider that in some cases coding with inheritance can lead to bloated code too. Consider the stack example that Skrien talks about on page 76. If you wanted to implement MyStack in such a way that you excluded all of the functionality that you didn't want to carry, the only way to do "void out" these methods would be to implement them and either do nothing or throw an exception [Skrien 76].
Delegation incurs performance overhead
- The process of delegation involves an extra method invocation when compared to inheritance. The performance penalty is most likely negligible. [Skrien, pg 77]. Skrien doesn't mention the vftable overhead involved with inheritance, so one could make an argument that Skrien should have called this one a draw.
Design Considerations
When faced with the choice of using inheritance or delegation, one of the first things the programmer may do is try to define whether the case represents the is-a or has-a relationship. The is-a maps to inheritance and the has-a relationship maps to delegation. But as we have seen, there isn't always an obvious way to determine which is the correct approach to take [9].
Resources
Object Oriented Design Using Java, Skrien
Dr. Dobbs: Composition vs. Inheritance
Design pattern for replacing inheritance with delegation
Game Object Structure: Inheritance vs. Aggregation
Classes, Structs, and Objects—Delegation and Composition vs. Inheritance
Composition vs. Inheritance, by Bill Venners, one of the original Gang of Four
Section on Composition vs. Inheritance from Design Principles article, by Bill Venners & Erich Gamma
Composition vs. Inheritance in Java
Wikipedia: Inheritance
Wikipedia: Delegation
Wikipedia: Composition