Composition, how do you know when to stop?

Question

There is an old, but wise saying, “Value over inheritance.” I tried to apply this, along with other OOP and Design-Patterns, for the last two projects in which I participated.

In most cases, it worked perfectly and looked right. But I noticed that on several occasions, there are only 2 or 3 classes that really get the best out of them, while the other 10+ classes suddenly become simple delegates with minor, varying details.

Sometimes I try to fix this using an abstract class with constant details that delegate variables for specific implementations, but something doesn’t seem like it at all.

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

Answer 1

I think your problem may be that you are trying to follow the "old wise sayings." You probably know the application requirements much better than any general recommendations.

Once you have gathered some experience building applications, you should get a natural idea of ​​how to do things. Guides are exactly what helps you understand the concept. They themselves are not rules.

Answer 2

“Value by inheritance” is an old saying that holds true today. Composition and inheritance are designed to increase reuse and reduce duplicate code. Inheritance also has other advantages.

Composition means that if you have a general method that belongs to 2 or more class hierarchies, separate it as a new class and let the class hierarchies have this new class as part of the composition. At the same time, you still do not touch the class hierarchy, you get the advantage of reusable code.

class Aves { ... } class Hawk: Aves { ... } class Mammal { ... } class Bat: Mammal { ... } 

In the above example, all Aves (birds) Fly (), (flightless birds such as Penguin or Dodo can still implement fly () without flying). But the bat, which is a mammal, can also fly ()

Now you can pull Fly () as a separate class and approve 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 embarrassed you yet :)

Answer 3

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

Focus on "is-a" and SRP to get the right inheritance.

The easiest way to check the SRP for classes is to try to associate the name of each method with the class name.

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

The WriteLog method cannot be associated with Vehicle . Break it and take it through the constructor (composition and dependency).

Answer 4

It looks like you are changing heuristic wisdom to absolute. This does not tell you to never use inheritance. If you are in a situation where either inheritance or composition works equally well, use composition. Plain.