Composition, how do you know when to stop? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question 开发者_开发技巧

There's the old but wise saying "Value composition over inheritance". I've been trying to apply this, along with other OOPs and Design-Patterns, for the last couple of projects that I've been involved in.

For most of the cases, it has worked fine and looked kind of right. But I've noticed that some times, there are just 2 or 3 classes that really get the best out of it, while other 10+ classes suddenly become kind of simple delegators with minor changing details.

Sometimes, I try to fix this by using an abstract class with the unvarying details that delegates the varying ones to the concrete implementations, but something doesn't feel completely right about it.

How do you keep balance of this and follow the old wise saying at the same time? Am I doing something wrong?

---

I think your problem may be that you are trying to follow the "old wise saying". You probably know much better the requirements of the application than any generic guidelines.

Once you have gathered some experience building applications, you should get a natural feel for how to do things. The guides are just that, guides to help you understand a concept. They are not rules in itself.

---

"Value composition over inheritance" is an old saying which is valid even today. Composition and inheritance are meant to increase the reusable & to reduce duplicate code. Inheritance has other benefits as well.

Composition means if you have generic method which belongs to 2 or more class hierarchy, separate it out as a new class and let the class hierarchies have this new class as part of composition. With this you don't touch the class hierarchy yet, you get the benefit of reusable code.

class Aves { ... }
class Hawk: Aves { ... }

class Mammal { ... }
class Bat: Mammal { ... }

In the above example, all Aves (birds) Fly(), (flightless birds like Penguin or Dodo still can implement fly() with no fly). But Bat which is a mammal can also fly()

You can now pull out Fly() as a separate class and favor composition over inheritance (including Fly() as part of Aves)

class FlyBehavior 
{
public void Fly() { ... }
}

FlyBehavior can be a class hierarchy with ShortFlightBehavior and LongFlightBehavior for example.

I hope I have not confused you further :)

---

When to stop? Stop focusing at composition at all. It will come naturally if you focus on other rules.

Focus on "is-a" and SRP to get proper inheritance instead.

The most easy way to check SRP for classes is to try to associate each method name to the class name.

class Vehicle
{
    private void WriteLog(string message) {}
    public void Start();
}

The WriteLog method can not really be associated with Vehicle. Break it out and take it in through the constructor instead (composition and dependency injection).

---

It sounds like you are changing the heuristic wisdom into an absolute. It is not telling you "never" to use inheritance. If you are in a situation where either inheritance or composition work equally well, then use composition. Simple.