CSC/ECE 517 Summer 2008/wiki2 8 jb: Difference between revisions
| Line 15: | Line 15: | ||
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 [http://en.wikipedia.org/wiki/Design_Patterns GoF, or Gang of Four], in their book titled [http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software]. The book stated to [http://www.artima.com/lejava/articles/designprinciples4.html "Favor object composition over class inheritance"] as design principle. This position is backed up by many strong arguments. | 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 [http://en.wikipedia.org/wiki/Design_Patterns GoF, or Gang of Four], in their book titled [http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software]. The book stated to [http://www.artima.com/lejava/articles/designprinciples4.html "Favor object composition over class inheritance"] as design principle. This position is backed up by many strong arguments. | ||
===Arguments against Inheritance=== | |||
====Inheritance breaks [http://en.wikipedia.org/wiki/Information_hiding encapsulation]==== | ====Inheritance breaks [http://en.wikipedia.org/wiki/Information_hiding encapsulation]==== | ||
<ul> | <ul> | ||
| Line 23: | Line 24: | ||
</ul> | </ul> | ||
===Inheritance increases [http://en.wikipedia.org/wiki/Coupling_(computer_science)#Object-oriented_programming coupling]=== | ====Inheritance increases [http://en.wikipedia.org/wiki/Coupling_(computer_science)#Object-oriented_programming coupling]==== | ||
<ul> | <ul> | ||
<li>Critics of inheritance argue that inheritance can lead to brittle code due to coupling between base and derived classes [http://www.eflorenzano.com/blog/post/inheritance-vs-composition/]. 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.</li> | <li>Critics of inheritance argue that inheritance can lead to brittle code due to coupling between base and derived classes [http://www.eflorenzano.com/blog/post/inheritance-vs-composition/]. 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.</li> | ||
| Line 29: | Line 30: | ||
</ul> | </ul> | ||
===Inheritance is static and determined at compile time=== | ====Inheritance is static and determined at compile time==== | ||
<ul> | <ul> | ||
<li>[http://en.csharp-online.net/Classes,_Structs,_and_Objects%E2%80%94Delegation_and_Composition_vs._Inheritance] </li> | <li>[http://en.csharp-online.net/Classes,_Structs,_and_Objects%E2%80%94Delegation_and_Composition_vs._Inheritance] </li> | ||
</ul> | </ul> | ||
===The Diamond of Death=== | ====The Diamond of Death==== | ||
<ul> | <ul> | ||
<li>[http://www.gamearchitect.net/Articles/GameObjects1.html] | <li>[http://www.gamearchitect.net/Articles/GameObjects1.html] | ||
</li> | </li> | ||
</ul> | |||
===Arguments against delegation=== | |||
====Bloated Code==== | |||
<ul> | |||
<li> [http://dobbscodetalk.com/index.php?option=com_myblog&show=Composition-vs-Inheritance.html&Itemid=29] </li> | |||
</ul> | </ul> | ||
Revision as of 01:32, 22 June 2008
This wiki will explore the age old debate of inheritance vs. delegation, showing the strengths and weakness of each approach, and where each approach is preferred.
Background
An in-depth definition of Inheritance and Delegation is out of the scope of this wiki, but a brief discussion of each approach 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.
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. The class which contains other classes is called the composite class, while a class being contained is called the composited or composed class [2].
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 protected access modifier breaks encapsulation by letting a derived class peer inside of its base class [3]
- interface inheritance
Inheritance increases coupling
- Critics of inheritance argue that inheritance can lead to brittle code due to coupling between base and derived classes [4]. 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. [5]. 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.
Inheritance is static and determined at compile time
The Diamond of Death
Arguments against delegation
Bloated Code
Links
Wikipedia: Inheritance
Wikipedia: Delegation
Wikipedia: Composition
Replace Inheritance With Delegation design pattern
Dr. Dobbs: Composition vs. Inheritance
Good debate
Great article covering delgation and composition
http://www.artima.com/designtechniques/compoinh.html
http://www.artima.com/lejava/articles/designprinciples4.html