Inheritance vs Aggregation

Posted: May 22, 2012 in Techilla

Inheritance vs Aggregation/ Composition vs Inheritance/ Is-a or Has-a ? Call it by any name, but this quandary is something which has baffled many design studies.
The other day I was designing some POC with Hibernate, and I got bitten by the performance bug. Having prior experience with Hibernate, I know what a beast it can be in terms of performance especially with complex inheritance mappings or associations .

As is often the case with me, one thing led to another and I veered down the Google way 🙂 . To paraphrase many eminent people, who have pretty much pushed me towards aggregation,let me provide a gist below:

An inheritance can always be rewritten as an association as follows

instead of


public class A {}
public class B extends A {}

we can use

public class B {
private A a;
}

We should use aggregation if part of the interface(available methods for us to override) is not used or has to be changed to avoid an illogical situation.

We only need to use inheritance, if we need almost all of the functionality without major changes. And when in doubt,we should always use Aggregation.
Also another line of thought was :
1.Whatever design strategy you choose, your choice will likely be the wrong one at some point because of changing requirements
2.Changing that choice is difficult once you’ve made it.
3.Inheritance tends to be a worse choice as it’s more constraining and hence we should go for aggregation.

To quote a discussion between Bill Venners and Erich Gamma  at:

Bill Venners: That extra flexibility of composition over inheritance is what I’ve observed, and it’s something I’ve always had difficulty explaining. That’s what I was hoping you could capture in words. Why? What is really going on? Where does the increased flexibility really come from?

Erich Gamma: We call this black box reuse. You have a container, and you plug in some smaller objects. These smaller objects configure the container and customize the behavior of the container. This is possible since the container delegates some behavior to the smaller thing. In the end you get customization by configuration. This provides you with both flexibility and reuse opportunities for the smaller things. That’s powerful. Rather than giving you a lengthy explanation, let me just point you to the Strategypattern. It is my prototypical example for the flexibility of composition over inheritance. The increased flexibility comes from the fact that you can plug-in different strategy objects and, moreovers, that you can even change the strategy objects dynamically at run-time.

Bill Venners: So if I were to use inheritance…

Erich Gamma: You can’t do this mix and match of strategy objects. In particular you cannot do it dynamically at run-time.

So, the writing’s on the wall for me. Choose aggregation over inheritance whenever you can, and hopefully, you will live to design another project before they find out that the design strategy implemented needs to be changed. 🙂

All info above are drawn from inheritance-vs-aggregation
and “Design principle” so all credit goes to original authors and I just summarized it above.

Advertisements
Comments
  1. click says:

    This website has a lot of very helpful stuff on it. Thanks for sharing it with me!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s