How would you design your application? By Inheritance or by Composition? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

This is a design question/discussion.

I created a solution which contains about 50 classes.

I refactored the classes and removed duplicated codes by introducing new abstract classes which contain shared information between classes so that those classes inherit from them.

E.g.

Abstract ColumnBuilder
ColumnBuilderForDepartmentReport : ColumnBuilder
ColumnBuilderForStoreReport : ColumnBuilder

No now my design contains lots of classes and duplicated codes have been removed which is a positive thin开发者_运维技巧g.

Is this a good design?

I've heard we should be preferring Composition over Inheritance.

How would it apply to these kind of scenarios where you want to use inheritance to remove duplicated code? Should I refactor the code to use Composition? How?

Thanks

---

You need both as the situation requires. Composition is preferred for creating classes, but inheritance makes sense when you need an 'is-a' relationship.

In your case, this means inheritance for the unique ColumnBuilder types, which can then be used in other classes by composition (for 'has-a' relationships).

For example, a Report class that has a ColumnBuilder, which allows you to assign either of your unique classes (and any future ColumnBuilder inheritors) thanks to the composition of an inheritable class type.

---

You missed out using Interfaces with Composition - this gives you the flexibility of Composition, but retains the polymorphism of inheritance.

E.g. you could define an interface: IColumnBuilder, and have all 3 classes implement this interface.

As to whether your code is designed well - cannot tell from the information provided. Lots of classes is not a bad thing - how long is a piece of string?

My rule of thumb:

1) Use inheritance when your subclass "is-a" superclass - in the example you cite they're all column builders so inheritance would be my choice. This makes it far easier to add new column builder types.

2) Use composition where all you're trying to achieve is code reuse.

3) If you're trying to get polymorphism, but rule 1 doesn't apply (no "is-a" relationship), then use composition with interfaces.

---

I've heard we should be preferring Composition over Inheritance.

Generally good advice. But it doesn't mean you should replace them all.

If your subclasses need all of what's in the superclasses and each subclass adds small bits of function, you might be fine to stay with inheritance.

How would it apply to these kind of scenarios where you want to use inheritance to remove duplicated code? Should I refactor the code to use Composition? How?

You can also use composition to remove duplicated code.

The refactoring you're looking for is Replace Inheritance with Delegation. Googling this phrase may find you a few references with more detail than a sample diagram, but you really ought to get the book Refactoring.