Why is composition better than inheritance

If you would have used Composition over inheritance, you will never face this problem. A simple example of ClassB implementation using Composition can be as below. This is one of the major advantage of composition over inheritance. Composition provides flexibility in invocation of methods that is useful with multiple subclass scenario.

No, we can rewrite the Test class like below. This will give you the flexibility to use any subclass based on the object used in the constructor. One more benefit of composition over inheritance is testing scope. Unit testing is easy in composition because we know what all methods we are using from another class.

So we will have to test all the methods of the superclass. This is extra work and we need to do it unnecessarily because of inheritance. You have got enough reasons to choose composition over inheritance. Use inheritance only when you are sure that superclass will not be changed, otherwise go for composition. I think we should not be comparing these two which one is better or not. Both inheritance and composition have different use case.

Whatever is explained in the article is syntactical things. We should prefer inheritance when we want to override behavior and re usability both but composition is straight forward example of re usability, or making of small components which together can make a big component. Please fix the formatting issue.

Everything after the Composition section is shown in code layout. Skip to content. Change Language. Related Articles. Table of Contents. Save Article. Improve Article. Like Article. Last Updated : 22 Feb, Previous Why java.

Mind you, global variables are not all THAT bad - databases are essentially big set of global variables. But if you can handle it, then it's quite fine. When you have an is-a relation between two classes example dog is a canine , you go for inheritance.

On the other hand when you have has-a or some adjective relationship between two classes student has courses or teacher studies courses , you chose composition. A simple way to make sense of this would be that inheritance should be used when you need an object of your class to have the same interface as its parent class, so that it can thereby be treated as an object of the parent class upcasting.

Moreover, function calls on a derived class object would remain the same everywhere in code, but the specific method to call would be determined at runtime i. Composition should be used when you do not need the new class to have the same interface, i. So composition is more in the way of supporting encapsulation i. Subtyping is appropriate and more powerful where the invariants can be enumerated , else use function composition for extensibility. I agree with Pavel, when he says, there are places for composition and there are places for inheritance.

However, if your intention is purely that of code re-use, then composition most likely is a better design choice. Inheritance is a very powerfull machanism for code reuse. But needs to be used properly. I would say that inheritance is used correctly if the subclass is also a subtype of the parent class. As mentioned above, the Liskov Substitution Principle is the key point here. Subclass is not the same as subtype. You might create subclasses that are not subtypes and this is when you should use composition.

To understand what a subtype is, lets start giving an explanation of what a type is. When we say that the number 5 is of type integer, we are stating that 5 belongs to a set of possible values as an example, see the possible values for the Java primitive types.

We are also stating that there is a valid set of methods I can perform on the value like addition and subtraction. And finally we are stating that there are a set of properties that are always satisfied, for example, if I add the values 3 and 5, I will get 8 as a result. To give another example, think about the abstract data types, Set of integers and List of integers, the values they can hold are restricted to integers. They both support a set of methods, like add newValue and size.

And they both have different properties class invariant , Sets does not allow duplicates while List does allow duplicates of course there are other properties that they both satisfy. Subtype is also a type, which has a relation to another type, called parent type or supertype.

The subtype must satisfy the features values, methods and properties of the parent type. The relation means that in any context where the supertype is expected, it can be substitutable by a subtype, without affecting the behaviour of the execution. Suppose I write a List of integers in some sort of pseudo language :. Our Set of integers class is a subclass of List of Integers, but is not a subtype, due to it is not satisfying all the features of the List class. The values, and the signature of the methods are satisfied but the properties are not.

The behaviour of the add Integer method has been clearly changed, not preserving the properties of the parent type. Think from the point of view of the client of your classes.

They might receive a Set of integers where a List of integers is expected. The client might want to add a value and get that value added to the List even if that value already exist in the List. But her wont get that behaviour if the value exists. A big suprise for her! Even though Composition is preferred, I would like to highlight pros of Inheritance and cons of Composition.

It establishes a logical " IS A" relation. If Car contains Vehicle and if you have to get price of the Car , which has been defined in Vehicle , your code will be like this. A rule of thumb I have heard is inheritance should be used when its a "is-a" relationship and composition when its a "has-a".

Even with that I feel that you should always lean towards composition because it eliminates a lot of complexity. There is no real answer for what is better as I think it all depends on the design of the system. If relation type is "IS-A" relation then Inheritance is better approach.

I see no one mentioned the diamond problem , which might arise with inheritance. In a glance, if classes B and C inherit A and both override method X, and a fourth class D, inherits from both B and C, and does not override X, which implementation of X D is supposed to use? Wikipedia offers a nice overview of the topic being discussed in this question.

As many people told, I will first start with the check - whether there exists an "is-a" relationship. If it exists I usually check the following:. Whether the base class can be instantiated. That is, whether the base class can be non-abstract. If it can be non-abstract I usually prefer composition.

Accountant is an Employee. But I will not use inheritance because a Employee object can be instantiated. Book is a SellingItem. A SellingItem cannot be instantiated - it is abstract concept. Hence I will use inheritacne. The SellingItem is an abstract base class or interface in C. Also, I support anon answer in Why use inheritance at all?

The main reason for using inheritance is not as a form of composition - it is so you can get polymorphic behaviour. If you don't need polymorphism, you probably should not be using inheritance. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Prefer composition over inheritance? Ask Question. Asked 13 years, 2 months ago.

Active 1 year, 1 month ago. Viewed k times. Improve this question. Taryn k 54 54 gold badges silver badges bronze badges. See also which class design is better — maccullt. Add a comment. Active Oldest Votes. My acid test for the above is: Does TypeB want to expose the complete interface all public methods no less of TypeA such that TypeB can be used where TypeA is expected?

A Cessna biplane will expose the complete interface of an airplane, if not more. So that makes it fit to derive from Airplane.

A Bird may need only the fly behavior of an Airplane. Improve this answer. Inanc Gumus Gishu Gishu k 46 46 gold badges silver badges bronze badges. The second example is straight out of the Head First Design Patterns amazon. It's very clear, but it may miss something : "Does TypeB want to expose the complete interface all public methods no less of TypeA such that TypeB can be used where TypeA is expected?

And what if TypeC hasn't been modeled yet? You allude to what I think should be the most basic test: "Should this object be usable by code which expects objects of what would be the base type". If the answer is yes, the object must inherit. If no, then it probably should not. If I had my druthers, languages would provide a keyword to refer to "this class", and provide a means of defining a class which should behave just like another class, but not be substitutable for it such a class would have all "this class" references replaced with itself.

Alexey - the point is 'Can I pass in a Cessna biplane to all clients that expect an airplane without surprising them? If yes, then chances are you want inheritance. I'm actually struggling to think of any examples where inheritance would have been my answer, I often find aggregation, composition and interfaces result in more elegant solutions.

Many of the above examples could possibly be better explained using those approaches Show 19 more comments. James Skemp 7, 9 9 gold badges 59 59 silver badges 98 98 bronze badges. Nick Zalutskiy Nick Zalutskiy This is not always a perfect approach, it's simply a good guideline.

And that's the whole point of this technique. If it sounds awkward, it is probably wrong. So you cannot base your decision on "has a" vs "is a" comparision, you have to use LSP, or you will make mistakes — Tristan. Instead of "is a" think of "behaves like.

This doesn't answer the question. The question is "why" not "what". Show 4 more comments. If you understand the difference, it's easier to explain. Inheritance This encourages the use of classes. Composition Composition is favoured over inheritance.

For inheritence: There is no ambiguity. You are implementing the Manager class based on requirements. So you would return "Manager of Operations" if thats what your requirements specified, else you would just use the base class's implementation. Also you could make Person an abstract class and thereby make sure down-stream classes implement a Title property.

Its important to remember that one might say "Composition over inheritence" but that does not mean "Composition always over Inheritence".

Employee is a Person Employee does not have a person. The example is confusing. Employee is a person, so it should use inheritance. You should not use composition for this example, because it is wrong relationship in domain model, even if technically you can declare it in the code. I disagree with this example. An Employee is-a Person, which is a textbook case of proper use of inheritance.

I also think that the "issue" the redefinition of the Title field does not make sense. The fact that Employee. Title shadows Person. Title is a sign of poor programming. After all, are "Mr. I would rename Employee. Title, and thus be able to reference the Title and JobTitle attributes of an Employee, both of which make sense in real life. Encapsulation: by interacting with objects instead of directly with the implementation of methods and fields, we hide and protect the implementation of a class.

If a consumer does not know anything about an object other than its public interface, then it cannot rely on any internal implementation details. Inheritance is Fundamental Inheritance is fundamental to object-oriented programming. Even if the language does not support composition rare these days!

It would be impossible to break down complex problems into modular solutions without composition. The big deal is in thinking that one can replace the other, in all cases, or that one is better or worse than the other. Like everything else in software development, there are trade-offs to be made. Composition is fairly easy to understand - we can see composition in everyday life: a chair has legs, a wall is composed of bricks and mortar, and so on.

While the definition of inheritance is simple, it can become a complicated, tangled thing when used unwisely. Inheritance is more of an abstraction that we can only talk about, not touch directly.

Though it is possible to mimic inheritance using composition in many situations, it is often unwieldy to do so. The purpose of composition is obvious: make wholes out of parts. The purpose of inheritance is a bit more complex because inheritance serves two purposes, semantics and mechanics. Inheritance Semantics Inheritance captures semantics meaning in a classification hierarchy a taxonomy , arranging concepts from generalized to specialized, grouping related concepts in subtrees, and so on.

The semantics of a class are mostly captured in its interface, the set of messages to which it responds, but a portion of the semantics also resides in the set of messages that the class sends. When inheriting from a class, you are implicitly accepting responsibility for all of the messages that the superclass sends on your behalf, not just the messages that it can receive.

This makes the subclass more tightly coupled to its superclass than it would be if it merely used an instance of the superclass as a component instead of inheriting from it. Inheritance Mechanics Inheritance captures mechanics by encoding the representation of the data fields and behavior methods of a class and making it available for reuse and augmentation in subclasses.

Mechanically, the subclass will inherit the implementation of the superclass and thus also its interface. The dual purpose of inheritance 7 in most current OOP languages is, I believe, the cause of most confusion.

An overemphasis on reuse can lead to tragically flawed designs.