Warning: Declaration of PageLinesBanners::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/banners/section.php on line 205

Warning: Declaration of PageLinesFeatures::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/features/section.php on line 254

Warning: Declaration of PageLinesFeatures::section_head($clone_id) should be compatible with PageLinesSection::section_head() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/features/section.php on line 61

Warning: Declaration of PageLinesHighlight::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/highlight/section.php on line 94

Warning: Declaration of PageLinesCarousel::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/carousel/section.php on line 168

Warning: Declaration of PLheroUnit::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/hero/section.php on line 140

Warning: Declaration of PLNavBar::section_template($clone_id, $location = '') should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/navbar/section.php on line 199

Warning: Declaration of PLMasthead::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/masthead/section.php on line 178

Warning: Declaration of PageLinesQuickSlider::section_template($clone_id) should be compatible with PageLinesSection::section_template() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/quickslider/section.php on line 59

Warning: Declaration of PageLinesQuickSlider::section_head($clone_id) should be compatible with PageLinesSection::section_head() in /home/c0nannet/public_html/blog/wp-content/themes/pagelines/sections/quickslider/section.php on line 29
{"id":268,"date":"2018-01-11T00:06:48","date_gmt":"2018-01-11T00:06:48","guid":{"rendered":"http:\/\/c0nan.net\/blog\/?p=268"},"modified":"2018-01-11T00:06:48","modified_gmt":"2018-01-11T00:06:48","slug":"inheritance-vs-composition-wars","status":"publish","type":"post","link":"https:\/\/c0nan.net\/blog\/inheritance-vs-composition-wars\/","title":{"rendered":"Inheritance vs Composition Wars"},"content":{"rendered":"

One of the fundamental activities of an object-oriented design is establishing relationships between classes. Two fundamental ways to relate classes are\u00a0inheritance<\/em>\u00a0and\u00a0composition<\/em>. Although the compiler and Java virtual machine (JVM) will do a lot of work for you when you use inheritance, you can also get at the functionality of inheritance when you use composition. This article will compare these two approaches to relating classes and will provide guidelines on their use. Source<\/a><\/p>\n

First, some background on the meaning of inheritance and composition.<\/p>\n

About inheritance<\/strong>\u00a0In this article, I’ll be talking about single inheritance through class extension, as in:<\/p>\n

class Fruit {\r\n \/\/...}\r\n\r\nclass Apple extends Fruit {\r\n \/\/... }<\/code><\/pre>\nIn this simple example, class\u00a0Apple<\/code>\u00a0is related to class\u00a0Fruit<\/code>\u00a0by inheritance, because\u00a0Apple<\/code>\u00a0extends\u00a0Fruit<\/code>. In this example,\u00a0Fruit<\/code>\u00a0is the\u00a0superclass<\/em>\u00a0and\u00a0Apple<\/code>is the\u00a0subclass<\/em>.<\/p>\n
<\/aside>\nI won’t be talking about multiple inheritance of interfaces through interface extension. That topic I’ll save for next month’s\u00a0Design Techniques<\/strong>\u00a0article, which will be focused on designing with interfaces.<\/p>\n
Here’s a UML diagram showing the inheritance relationship between\u00a0Apple<\/code>\u00a0and\u00a0Fruit<\/code>:<\/p>\n
Figure 1. The inheritance relationship<\/figcaption><\/figure>\nAbout composition<\/strong>\u00a0By composition, I simply mean using instance variables that are references to other objects. For example:<\/p>\n
class Fruit {\r\n\/\/... }\r\nclass Apple {\r\nprivate Fruit fruit = new Fruit(); \/\/... }<\/code><\/pre>\nIn the example above, class\u00a0Apple<\/code>\u00a0is related to class\u00a0Fruit<\/code>\u00a0by composition, because\u00a0Apple<\/code>\u00a0has an instance variable that holds a reference to a\u00a0Fruit<\/code>\u00a0object. In this example,\u00a0Apple<\/code>\u00a0is what I will call the\u00a0front-end class<\/em>\u00a0and\u00a0Fruit<\/code>\u00a0is what I will call the\u00a0back-end class<\/em>. In a composition relationship, the front-end class holds a reference in one of its instance variables to a back-end class.<\/p>\n
The UML diagram showing the composition relationship has a darkened diamond, as in:<\/p>\n
Figure 2. The composition relationship<\/figcaption><\/figure>\nDynamic binding, polymorphism, and change<\/h2>\nWhen you establish an inheritance relationship between two classes, you get to take advantage of\u00a0dynamic binding<\/em>\u00a0and\u00a0polymorphism.<\/em>\u00a0Dynamic binding means the JVM will decide at runtime which method implementation to invoke based on the class of the object. Polymorphism means you can use a variable of a superclass type to hold a reference to an object whose class is the superclass or any of its subclasses.<\/p>\n
One of the prime benefits of dynamic binding and polymorphism is that they can help make code easier to change. If you have a fragment of code that uses a variable of a superclass type, such as\u00a0Fruit<\/code>, you could later create a brand new subclass, such as\u00a0Banana<\/code>, and the old code fragment will work without change with instances of the new subclass. If\u00a0Banana<\/code>\u00a0overrides any of\u00a0Fruit<\/code>‘s methods that are invoked by the code fragment, dynamic binding will ensure that\u00a0Banana<\/code>‘s implementation of those methods gets executed. This will be true even though class\u00a0Banana<\/code>\u00a0didn’t exist when the code fragment was written and compiled.<\/p>\n
Thus, inheritance helps make code easier to change if the needed change involves adding a new subclass. This, however, is not the only kind of change you may need to make.<\/p>\n
Changing the superclass interface<\/h2>\nIn an inheritance relationship, superclasses are often said to be “fragile,” because one little change to a superclass can ripple out and require changes in many other places in the application’s code. To be more specific, what is actually fragile about a superclass is its interface. If the superclass is well-designed, with a clean separation of interface and implementation in the object-oriented style, any changes to the superclass’s implementation shouldn’t ripple at all. Changes to the superclass’s interface, however, can ripple out and break any code that uses the superclass or any of its subclasses. What’s more, a change in the superclass interface can break the code that defines any of its subclasses.<\/p>\n
For example, if you change the return type of a public method in class\u00a0Fruit<\/code>\u00a0(a part of\u00a0Fruit<\/code>‘s interface), you can break the code that invokes that method on any reference of type\u00a0Fruit<\/code>\u00a0or any subclass of\u00a0Fruit<\/code>. In addition, you break the code that defines any subclass of\u00a0Fruit<\/code>\u00a0that overrides the method. Such subclasses won’t compile until you go and change the return value of the overridden method to match the changed method in superclass\u00a0Fruit<\/code>.<\/p>\n
Inheritance is also sometimes said to provide “weak encapsulation,” because if you have code that directly uses a subclass, such as\u00a0Apple<\/code>, that code can be broken by changes to a superclass, such as\u00a0Fruit<\/code>. One of the ways to look at inheritance is that it allows subclass code to\u00a0reuse<\/em>\u00a0superclass code. For example, if\u00a0Apple<\/code>\u00a0doesn’t override a method defined in its superclass\u00a0Fruit<\/code>,\u00a0Apple<\/code>\u00a0is in a sense reusing\u00a0Fruit<\/code>‘s implementation of the method. But\u00a0Apple<\/code>only “weakly encapsulates” the\u00a0Fruit<\/code>\u00a0code it is reusing, because changes to\u00a0Fruit<\/code>‘s interface can break code that directly uses\u00a0Apple<\/code>.<\/p>\n
The composition alternative<\/h2>\nGiven that the inheritance relationship makes it hard to change the interface of a superclass, it is worth looking at an alternative approach provided by composition. It turns out that when your goal is code reuse, composition provides an approach that yields easier-to-change code.<\/p>\n
<\/aside>\nCode reuse via inheritance<\/strong>\u00a0For an illustration of how inheritance compares to composition in the code reuse department, consider this very simple example:<\/p>\n
class<\/span> Fruit<\/span> {<\/span>\r\n\r\n\/\/ Return int number of pieces of peel that<\/span> \/\/ resulted from the peeling activity.<\/span> public<\/span> int<\/span> peel<\/span>()<\/span> {<\/span>\r\n\r\nSystem<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"Peeling is appealing.\"<\/span>);<\/span> return<\/span> 1<\/span>;<\/span> }<\/span> }<\/span>\r\n\r\nclass<\/span> Apple<\/span> extends<\/span> Fruit<\/span> {<\/span> }<\/span>\r\n\r\nclass<\/span> Example1<\/span> {<\/span>\r\n\r\npublic<\/span> static<\/span> void<\/span> main<\/span>(<\/span>String<\/span>[]<\/span> args<\/span>)<\/span> {<\/span>\r\n\r\nApple<\/span> apple <\/span>=<\/span> new<\/span> Apple<\/span>();<\/span> int<\/span> pieces <\/span>=<\/span> apple<\/span>.<\/span>peel<\/span>();<\/span> }<\/span> }<\/span><\/pre>\nWhen you run the\u00a0Example1<\/code>\u00a0application, it will print out\u00a0\"Peeling is appealing.\"<\/code>, because\u00a0Apple<\/code>\u00a0inherits (reuses)\u00a0Fruit<\/code>‘s implementation of\u00a0peel()<\/code>. If at some point in the future, however, you wish to change the return value of\u00a0peel()<\/code>\u00a0to type\u00a0Peel<\/code>, you will break the code for\u00a0Example1<\/code>. Your change to\u00a0Fruit<\/code>breaks\u00a0Example1<\/code>‘s code even though\u00a0Example1<\/code>\u00a0uses\u00a0Apple<\/code>\u00a0directly and never explicitly mentions\u00a0Fruit<\/code>.<\/p>\n
Here’s what that would look like:<\/p>\n
class<\/span> Peel<\/span> {<\/span>\r\n\r\nprivate<\/span> int<\/span> peelCount<\/span>;<\/span>\r\n\r\npublic<\/span> Peel<\/span>(<\/span>int<\/span> peelCount<\/span>)<\/span> {<\/span> this<\/span>.<\/span>peelCount <\/span>=<\/span> peelCount<\/span>;<\/span> }<\/span>\r\n\r\npublic<\/span> int<\/span> getPeelCount<\/span>()<\/span> {<\/span>\r\n\r\nreturn<\/span> peelCount<\/span>;<\/span> }<\/span> \/\/...<\/span> }<\/span>\r\n\r\nclass<\/span> Fruit<\/span> {<\/span>\r\n\r\n\/\/ Return a Peel object that<\/span> \/\/ results from the peeling activity.<\/span> public<\/span> Peel<\/span> peel<\/span>()<\/span> {<\/span>\r\n\r\nSystem<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"Peeling is appealing.\"<\/span>);<\/span> return<\/span> new<\/span> Peel<\/span>(<\/span>1<\/span>);<\/span> }<\/span> }<\/span>\r\n\r\n\/\/ Apple still compiles and works fine<\/span> class<\/span> Apple<\/span> extends<\/span> Fruit<\/span> {<\/span> }<\/span>\r\n\r\n\/\/ This old implementation of Example1<\/span> \/\/ is broken and won't compile.<\/span> class<\/span> Example1<\/span> {<\/span>\r\n\r\npublic<\/span> static<\/span> void<\/span> main<\/span>(<\/span>String<\/span>[]<\/span> args<\/span>)<\/span> {<\/span>\r\n\r\nApple<\/span> apple <\/span>=<\/span> new<\/span> Apple<\/span>();<\/span> int<\/span> pieces <\/span>=<\/span> apple<\/span>.<\/span>peel<\/span>();<\/span> }<\/span> }<\/span><\/pre>\nCode reuse via composition<\/strong>\u00a0Composition provides an alternative way for\u00a0Apple<\/code>to reuse\u00a0Fruit<\/code>‘s implementation of\u00a0peel()<\/code>. Instead of extending\u00a0Fruit<\/code>,\u00a0Apple<\/code>can hold a reference to a\u00a0Fruit<\/code>\u00a0instance and define its own\u00a0peel()<\/code>\u00a0method that simply invokes\u00a0peel()<\/code>\u00a0on the\u00a0Fruit<\/code>. Here’s the code:<\/p>\n
class<\/span> Fruit<\/span> {<\/span>\r\n\r\n\/\/ Return int number of pieces of peel that<\/span> \/\/ resulted from the peeling activity.<\/span> public<\/span> int<\/span> peel<\/span>()<\/span> {<\/span>\r\n\r\nSystem<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"Peeling is appealing.\"<\/span>);<\/span> return<\/span> 1<\/span>;<\/span> }<\/span> }<\/span>\r\n\r\nclass<\/span> Apple<\/span> {<\/span>\r\n\r\nprivate<\/span> Fruit<\/span> fruit <\/span>=<\/span> new<\/span> Fruit<\/span>();<\/span>\r\n\r\npublic<\/span> int<\/span> peel<\/span>()<\/span> {<\/span> return<\/span> fruit<\/span>.<\/span>peel<\/span>();<\/span> }<\/span> }<\/span>\r\n\r\nclass<\/span> Example2<\/span> {<\/span>\r\n\r\npublic<\/span> static<\/span> void<\/span> main<\/span>(<\/span>String<\/span>[]<\/span> args<\/span>)<\/span> {<\/span>\r\n\r\nApple<\/span> apple <\/span>=<\/span> new<\/span> Apple<\/span>();<\/span> int<\/span> pieces <\/span>=<\/span> apple<\/span>.<\/span>peel<\/span>();<\/span> }<\/span> }<\/span><\/pre>\nIn the composition approach, the subclass becomes the “front-end class,” and the superclass becomes the “back-end class.” With inheritance, a subclass automatically inherits an implemenation of any non-private superclass method that it doesn’t override. With composition, by contrast, the front-end class must explicitly invoke a corresponding method in the back-end class from its own implementation of the method. This explicit call is sometimes called “forwarding” or “delegating” the method invocation to the back-end object.<\/p>\n
The composition approach to code reuse provides stronger encapsulation than inheritance, because a change to a back-end class needn’t break any code that relies only on the front-end class. For example, changing the return type of\u00a0Fruit<\/code>‘s\u00a0peel()<\/code>\u00a0method from the previous example doesn’t force a change in\u00a0Apple<\/code>‘s interface and therefore needn’t break\u00a0Example2<\/code>‘s code.<\/p>\n
Here’s how the changed code would look:<\/p>\n
class<\/span> Peel<\/span> {<\/span>\r\n\r\nprivate<\/span> int<\/span> peelCount<\/span>;<\/span>\r\n\r\npublic<\/span> Peel<\/span>(<\/span>int<\/span> peelCount<\/span>)<\/span> {<\/span> this<\/span>.<\/span>peelCount <\/span>=<\/span> peelCount<\/span>;<\/span> }<\/span>\r\n\r\npublic<\/span> int<\/span> getPeelCount<\/span>()<\/span> {<\/span>\r\n\r\nreturn<\/span> peelCount<\/span>;<\/span> }<\/span> \/\/...<\/span> }<\/span>\r\n\r\nclass<\/span> Fruit<\/span> {<\/span>\r\n\r\n\/\/ Return int number of pieces of peel that<\/span> \/\/ resulted from the peeling activity.<\/span> public<\/span> Peel<\/span> peel<\/span>()<\/span> {<\/span>\r\n\r\nSystem<\/span>.<\/span>out<\/span>.<\/span>println<\/span>(<\/span>\"Peeling is appealing.\"<\/span>);<\/span> return<\/span> new<\/span> Peel<\/span>(<\/span>1<\/span>);<\/span> }<\/span> }<\/span>\r\n\r\n\/\/ Apple must be changed to accomodate<\/span> \/\/ the change to Fruit<\/span> class<\/span> Apple<\/span> {<\/span>\r\n\r\nprivate<\/span> Fruit<\/span> fruit <\/span>=<\/span> new<\/span> Fruit<\/span>();<\/span>\r\n\r\npublic<\/span> int<\/span> peel<\/span>()<\/span> {<\/span>\r\n\r\nPeel<\/span> peel <\/span>=<\/span> fruit<\/span>.<\/span>peel<\/span>();<\/span> return<\/span> peel<\/span>.<\/span>getPeelCount<\/span>();<\/span> }<\/span> }<\/span>\r\n\r\n\/\/ This old implementation of Example2<\/span> \/\/ still works fine.<\/span> class<\/span> Example1<\/span> {<\/span>\r\n\r\npublic<\/span> static<\/span> void<\/span> main<\/span>(<\/span>String<\/span>[]<\/span> args<\/span>)<\/span> {<\/span>\r\n\r\nApple<\/span> apple <\/span>=<\/span> new<\/span> Apple<\/span>();<\/span> int<\/span> pieces <\/span>=<\/span> apple<\/span>.<\/span>peel<\/span>();<\/span> }<\/span> }<\/span><\/pre>\nThis example illustrates that the ripple effect caused by changing a back-end class stops (or at least can stop) at the front-end class. Although\u00a0Apple<\/code>‘s\u00a0peel()<\/code>method had to be updated to accommodate the change to\u00a0Fruit<\/code>,\u00a0Example2<\/code>required no changes.<\/p>\n
Comparing composition and inheritance<\/h2>\nSo how exactly do composition and inheritance compare? Here are several points of comparison:<\/p>\n
\nIt is easier to change the interface of a back-end class (composition) than a superclass (inheritance). As the previous example illustrated, a change to the interface of a back-end class necessitates a change to the front-end class implementation, but not necessarily the front-end interface. Code that depends only on the front-end interface still works, so long as the front-end interface remains the same. By contrast, a change to a superclass’s interface can not only ripple down the inheritance hierarchy to subclasses, but can also ripple out to code that uses just the subclass’s interface.<\/li>\n
It is easier to change the interface of a front-end class (composition) than a subclass (inheritance). Just as superclasses can be fragile, subclasses can be rigid. You can’t just change a subclass’s interface without making sure the subclass’s new interface is compatible with that of its supertypes. For example, you can’t add to a subclass a method with the same signature but a different return type as a method inherited from a superclass. Composition, on the other hand, allows you to change the interface of a front-end class without affecting back-end classes.<\/li>\n
Composition allows you to delay the creation of back-end objects until (and unless) they are needed, as well as changing the back-end objects dynamically throughout the lifetime of the front-end object. With inheritance, you get the image of the superclass in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.<\/li>\n
It is easier to add new subclasses (inheritance) than it is to add new front-end classes (composition), because inheritance comes with polymorphism. If you have a bit of code that relies only on a superclass interface, that code can work with a new subclass without change. This is not true of composition, unless you use composition with interfaces. Used together, composition and interfaces make a very powerful design tool. I’ll talk about this approach in next month’s\u00a0Design Techniques<\/strong>\u00a0article.<\/li>\n
The explicit method-invocation forwarding (or delegation) approach of composition will often have a performance cost as compared to inheritance’s single invocation of an inherited superclass method implementation. I say “often” here because the performance really depends on many factors, including how the JVM optimizes the program as it executes it.<\/li>\n
With both composition and inheritance, changing the implementation (not the interface) of any class is easy. The ripple effect of implementation changes remain inside the same class.<\/li>\n<\/ul>\nChoosing between composition and inheritance<\/h2>\nSo how do all these comparisons between composition and inheritance help you in your designs? Here are a few guidelines that reflect how I tend to select between composition and inheritance.<\/p>\n
Make sure inheritance models the\u00a0is-a<\/em>\u00a0relationship<\/strong>\u00a0My main guiding philosophy is that inheritance should be used only when a subclass\u00a0is-a<\/em>\u00a0superclass. In the example above, an\u00a0Apple<\/code>\u00a0likely is-a\u00a0Fruit<\/code>, so I would be inclined to use inheritance.<\/p>\n
An important question to ask yourself when you think you have an is-a relationship is whether that is-a relationship will be constant throughout the lifetime of the application and, with luck, the lifecycle of the code. For example, you might think that an\u00a0Employee<\/code>\u00a0is-a\u00a0Person<\/code>, when really\u00a0Employee<\/code>\u00a0represents a role that a\u00a0Person<\/code>\u00a0plays part of the time. What if the person becomes unemployed? What if the person is both an\u00a0Employee<\/code>\u00a0and a\u00a0Supervisor<\/code>? Such impermanent is-a relationships should usually be modelled with composition.<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the fundamental activities of an object-oriented design is establishing relationships between classes. Two fundamental ways to relate classes are\u00a0inheritance\u00a0and\u00a0composition. Although the compiler and Java virtual machine (JVM) will do a lot of work for you when you use inheritance, you can also get at the functionality of inheritance when you use composition. This […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/posts\/268"}],"collection":[{"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/comments?post=268"}],"version-history":[{"count":1,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/posts\/268\/revisions"}],"predecessor-version":[{"id":269,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/posts\/268\/revisions\/269"}],"wp:attachment":[{"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/media?parent=268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/categories?post=268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/c0nan.net\/blog\/wp-json\/wp\/v2\/tags?post=268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}