Mixing
Composition over inheritance
 |
This article may be confusing or unclear to readers. (October 2015) (Learn how and when to remove this template message) |
This diagram shows how the fly and sound behavior of an animal can be designed in a flexible way by using the composition over inheritance design principle.[1]
Composition over inheritance (or composite reuse principle) in object-oriented programming (OOP) is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.[2] This is an often-stated principle of OOP, such as in the influential book Design Patterns.[3]
Contents
1 Basics
2 Example
2.1 Inheritance
2.2 Composition and interfaces
3 Benefits
4 Drawbacks
5 Empirical studies
6 See also
7 References
Basics
An implementation of composition over inheritance typically begins with the creation of various interfaces representing the behaviors that the system must exhibit. Interfaces enable polymorphic behavior. Classes implementing the identified interfaces are built and added to business domain classes as needed. Thus, system behaviors are realized without inheritance.
In fact, business domain classes may all be base classes without any inheritance at all. Alternative implementation of system behaviors is accomplished by providing another class that implements the desired behavior interface. A class that contain a reference to an interface can support implementations of the interface - a choice that can be delayed until run time.
Example
Inheritance
An example in C++11 follows:
class GameObject {
public:
virtual ~GameObject() {}
virtual void update() {}
virtual void draw() {}
virtual void collide(GameObject objects) {}
};
class Visible : public GameObject {
public:
void draw() override { /* draw model at position of this object */ };
private:
Model* model;
};
class Solid : public GameObject {
public:
void collide(GameObject objects) override { /* check and react to collisions with objects */ };
};
class Movable : public GameObject {
public:
void update() override { /* update position */ };
};
Then, we have concrete classes:
- class
Player- which isSolid,MovableandVisible
- class
Cloud- which isMovableandVisible, but notSolid
- class
Building- which isSolidandVisible, but notMovable
- class
Trap- which isSolid, but neitherVisiblenorMovable
Note that multiple inheritance is dangerous if not implemented carefully, as it can lead to the diamond problem. One solution to avoid this is to create classes such as VisibleAndSolid, VisibleAndMovable, VisibleAndSolidAndMovable, etc. for every needed combination, though this leads to a large amount of repetitive code. Keep in mind that C++ solves the diamond problem of multiple inheritance by allowing virtual inheritance.
Composition and interfaces
The following C# example demonstrates the principle of using composition and interfaces to achieve code reuse and polymorphism.
class Program {
static void Main() {
var player = new Player();
player.Update();
player.Collide();
player.Draw();
}
}
interface IVisible {
void Draw();
}
class Invisible : IVisible {
public void Draw() {
Console.Write("I won't appear.");
}
}
class Visible : IVisible {
public void Draw() {
Console.Write("I'm showing myself.");
}
}
interface ICollidable {
void Collide();
}
class Solid : ICollidable {
public void Collide() {
Console.Write("Bang!");
}
}
class NotSolid : ICollidable {
public void Collide() {
Console.Write("Splash!");
}
}
interface IUpdatable {
void Update();
}
class Movable : IUpdatable {
public void Update() {
Console.Write("Moving forward.");
}
}
class NotMovable : IUpdatable {
public void Update() {
Console.Write("I'm staying put.");
}
}
abstract class GameObject : IVisible, IUpdatable, ICollidable {
private readonly IVisible _v;
private readonly IUpdatable _u;
private readonly ICollidable _c;
public GameObject(IVisible visible, IUpdatable updatable, ICollidable collidable) {
_v = visible;
_u = updatable;
_c = collidable;
}
public void Update() {
_u.Update();
}
public void Draw() {
_v.Draw();
}
public void Collide() {
_c.Collide();
}
}
class Player : GameObject {
public Player() : base(new Visible(), new Movable(), new Solid()) { }
}
class Cloud : GameObject {
public Cloud() : base(new Visible(), new Movable(), new NotSolid()) { }
}
class Building : GameObject {
public Building() : base(new Visible(), new NotMovable(), new Solid()) { }
}
class Trap : GameObject {
public Trap() : base(new Invisible(), new NotMovable(), new Solid()) { }
}
Benefits
To favor composition over inheritance is a design principle that gives the design higher flexibility. It is more natural to build business-domain classes out of various components than trying to find commonality between them and creating a family tree. For example, a gas pedal and a wheel share very few common traits, yet are both vital components in a car. What they can do and how they can be used to benefit the car is easily defined. Composition also provides a more stable business domain in the long term as it is less prone to the quirks of the family members. In other words, it is better to compose what an object can do (HAS-A) than extend what it is (IS-A).[1]
Initial design is simplified by identifying system object behaviors in separate interfaces instead of creating a hierarchical relationship to distribute behaviors among business-domain classes via inheritance. This approach more easily accommodates future requirements changes that would otherwise require a complete restructuring of business-domain classes in the inheritance model. Additionally, it avoids problems often associated with relatively minor changes to an inheritance-based model that includes several generations of classes.
Some languages, notably Go, use type composition exclusively.[4]
Drawbacks
One common drawback of using composition instead of inheritance is that methods being provided by individual components may have to be implemented in the derived type, even if they are only forwarding methods. In contrast, inheritance does not require all of the base class's methods to be re-implemented within the derived class. Rather, the derived class only needs to implement (override) the methods having different behavior than the base class methods. This can require significantly less programming effort if the base class contains many methods providing default behavior and only a few of them need to be overridden within the derived class.
For example, in the C# code below, the variables and methods of the Employee base class are inherited by the HourlyEmployee and SalariedEmployee derived subclasses. Only the Pay() method needs to be implemented (specialized) by each derived subclass. The other methods are implemented by the base class itself, and are shared by all of its derived subclasses; they do not need to be re-implemented (overridden) or even mentioned in the subclass definitions.
// Base class
public abstract class Employee
{
// Properties
protected string Name { get; set; }
protected int ID { get; set; }
protected decimal PayRate { get; set; }
protected int HoursWorked { get; }
// Get pay for the current pay period
abstract public decimal Pay();
}
// Derived subclass
public class HourlyEmployee: Employee
{
// Get pay for the current pay period
override public decimal Pay()
{
// Time worked is in hours
return HoursWorked * PayRate;
}
}
// Derived subclass
public class SalariedEmployee: Employee
{
// Get pay for the current pay period
override public decimal Pay()
{
// Pay rate is annual salary instead of hourly rate
return HoursWorked * PayRate/2087;
}
}
This drawback can be avoided by using traits, mixins, or protocol extensions. Some languages, such as Perl 6, provide a handles keyword to facilitate method forwarding. In Java, Project Lombok[5] allows delegation to be implemented using a single @Delegate annotation on the field, instead of copying and maintaining the names and types of all the methods from the delegated field.[6] In Swift, extensions can be used to define a default implementation of a protocol on the protocol itself, rather than within an individual type's implementation.[7] In Kotlin the delegation pattern has been included into the language syntax.[8]
Empirical studies
A 2013 study of 93 open source Java programs (of varying size) found that:
.mw-parser-output .templatequote{overflow:hidden;margin:1em 0;padding:0 40px}.mw-parser-output .templatequote .templatequotecite{line-height:1.5em;text-align:left;padding-left:1.6em;margin-top:0}
While there is not huge [sic] opportunity to replace inheritance with composition (...), the opportunity is significant (median of 2% of uses [of inheritance] are only internal reuse, and a further 22% are only external or internal reuse).
Our results suggest there is no need for concern regarding abuse of inheritance (at least in open-source Java software), but they do highlight the question regarding use of composition versus inheritance. If there are significant costs associated with using inheritance when composition could be used, then our results suggest there is some cause for concern.
— Tempero et al., "What programmers do with inheritance in Java"[9]
See also
- Delegation pattern
- Liskov substitution principle
- Object-oriented design
- Role-oriented programming
- State pattern
- Strategy pattern
References
^ ab Freeman, Eric; Robson, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Head First Design Patterns. O'Reilly. p. 23. ISBN 978-0-596-00712-6..mw-parser-output cite.citation{font-style:inherit}.mw-parser-output .citation q{quotes:"""""""'""'"}.mw-parser-output .citation .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-limited a,.mw-parser-output .citation .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .citation .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration{color:#555}.mw-parser-output .cs1-subscription span,.mw-parser-output .cs1-registration span{border-bottom:1px dotted;cursor:help}.mw-parser-output .cs1-ws-icon a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Wikisource-logo.svg/12px-Wikisource-logo.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output code.cs1-code{color:inherit;background:inherit;border:inherit;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;font-size:100%}.mw-parser-output .cs1-visible-error{font-size:100%}.mw-parser-output .cs1-maint{display:none;color:#33aa33;margin-left:0.3em}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration,.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left,.mw-parser-output .cs1-kern-wl-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right,.mw-parser-output .cs1-kern-wl-right{padding-right:0.2em}
^ Knoernschild, Kirk (2002). Java Design - Objects, UML, and Process: 1.1.5 Composite Reuse Principle (CRP). Addison-Wesley Inc. Retrieved 2012-05-29.
^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. p. 20. ISBN 0-201-63361-2. OCLC 31171684.
^ Pike, Rob (2012-06-25). "Less is exponentially more". Retrieved 2016-10-01.
^ http://projectlombok.org/
^ "@Delegate". Project Lombok. Retrieved 2018-07-11.
^ "Protocols". The Swift Programming Language. Apple Inc. Retrieved 2018-07-11.
^ "Delegated Properties". Kotlin Reference. JetBrains. Retrieved 2018-07-11.
^ Tempero, Ewan; Yang, Hong Yul; Noble, James (2013). What programmers do with inheritance in Java (PDF). ECOOP 2013–Object-Oriented Programming. pp. 577–601.
Comments
Post a Comment