"Is a" vs "Has a" : which one is better?

Question

Portfolio A → Fund 1

Portfolio A → Fund 2

Portfolio A → Fund 3

I couldn't frame my sentence without not using is/has. But between 1 & 2,

1) has a:

class PortfolioA
{
    List<Fund> obj;
}

2) is a:

class PortfolioA : List<Fund>
{

}

which one do you think is better from the point of extensibility, usability? I can still access my funds either way, albeit with a small syntactical change.

Solution 1

I vote with the other folks who say HAS-A is better in this case. You ask in a comment:

when I say that a Portfolio is just a collection of funds, with a few attributes of its own like TotalPortfolio etc, does that fundamentally not become an "is-a"?

I don't think so. If you say Portfolio IS-A List<Fund>, what about other properties of the Portfolio? Of course you can add properties to this class, but is it accurate to model those properties as properties of the List? Because that's basically what you're doing.

Also what if a Portfolio is required to support more than one List<Fund>? For instance, you might have one List that shows the current balance of investments, but another List that shows how new contributions are invested. And what about when funds are discontinued, and a new set of funds is used to succeed them? Historical information is useful to track, as well as the current fund allocation.

The point is that all these properties are not correctly properties of a List, though they may be properties of the Portfolio.

Solution 2

do not 'always' favor composition or inheritance or vice-versa; they have different semantics (meanings); look carefully at the meanings, then decide - it doesn't matter if one is 'easier' than the other, for longevity it matters that you get the semantics right

remember: is-a = type, has-a = containment

so in this case, a portfolio logically is a collection of funds; a portfolio itself is not a type of fund, so composition is the correct relationship

EDIT: I misread the question originally, but the answer is still the same. A Portfolio is not a type of list, it is a distinct entity with its own properties. For example, a portfolio is an aggregate of financial instruments with an initial investment cost, a total current value, a history of values over time, etc., while a List is a simple collection of objects. A portfolio is a 'type of list' only in the most abstract sense.

EDIT 2: think about the definition of portfolio - it is, without exception, characterized as a collection of things. An artist's portfolio is a collection of their artwork, a web designer's portfolio is a collection of their web sites, an investor's portfolio consists of all of the financial instruments that they own, and so on. So clearly we need a list (or some kind) to represent a portfolio, but that in no way implies that a portfolio is a type of list!

suppose we decide to let Portfolio inherit from List. This works until we add a Stock or Bond or Precious Metal to the Portfolio, and then suddenly the incorrect inheritance no longer works. Or suppose we are asked to model, say, Bill Gates' portfolio, and find that List will run out of memory ;-) More realistically, after future refactoring we will probably find that we should inherit from a base class like Asset, but if we've already inherited from List then we can't.

Summary: distinguish between the data structures we choose to represent a concept, and the semantics (type hierarchy) of the concept itself.

Solution 3

The first one, because you should try to favour composition over inheritance when you can.

Solution 4

It depends whether the business defines a Portfolio as a group (and only a group) of funds. If there is even the remote possibility of that it could contain other objects, say "property", then go with option 1. Go with option 2 if there is a strong link between a group of funds and the concept of Portfolio.

As far as extensibility and usefullness 1 has the slight advantage over 2. I really disagree with the concept that you should always favour one over the other. It really depends on what the actual real life concepts are. Remember, you can always^ refactor.

^ For most instances of always. If it is exposed publicly, then obviously not.

Solution 5

The first one, because it is "consists of". => Composition

View more solutions

Comments

[nawfal]

Also see prefer-composition-over-inheritance?

[Melebius]

Does this answer your question? Prefer composition over inheritance?

[Blorgbeard]

Can you justify that statement?

[Bill Karwin]

I wouldn't phrase it that way.

[Bill K]

He's right, always when you can. Maybe not always, but it's pretty much always preferable unless it's a no-brainer. Google "Extends is evil" for more info.

[baash05]

I agree with Rob here. I own a bonds and stocks and ira's, therefore my portfolio is not a list of my funds. I also agree with the not one over the other. If it "is a" then it is. If it "has a" then it does..

[aliensurfer]

I was referring to that kind of accessibility usefulness. But then from a purist perspective, a "has-a" sounds more appropriate. I agree on one reply from above. Essentially it is how the business (and you) perceive it to be.

[Steven A. Lowe]

@PrakashR: I actually misread the question and thought you wanted to make Portfolio a subclass of Fund ;-) It would be even worse to make Portfolio a subclass of List, because List is a generic collection and a Portfolio is a legal entity. Portfolios have a total value at time t, lists do not, etc.

[Charles Bretana]

In a sense, collection classes are kinda the exception to the purist approach for me, cause by definition, a collection of things "Has a" bunch of those things in it... It's the very nature of a collection...

[Charles Bretana]

I would draw the line when the parent object contains more than one collection of different classes of subordinate objects... like if you are modeling a sports team, with an internal collection of Players, and another internal collection of scheduled games, and another collection of Coaches, etc...

[Charles Bretana]

But if I had to model a MailingList object, that only had one internal collection, of, say, emailaddresses, then I would name it EmailAddressCollection, and use "Is A" semantics instead of "Has A"

[Parappa]

I agree that "has-a" should be preferred to "is-a" but you shouldn't say "always." :)

[Charles Bretana]

If that happened then "has a" might be better... But I might examine a model where the class represented a collection of a base class (say "Asset" objects) that all those things you mentioned derive from... If that 'worked' I would stick with "Is a"... Again I think collections are an exception

[Charles Bretana]

Another model I have used, is analogous to the file system folder-file structure... In this example, allow a "Portfolio" to represent (it "Is a") collection of other Portfolios... and each individual Portfolio to "have a" collection of Asset objects... (Funds, stocks, bonds, cars, houses, etc.)

[Steven A. Lowe]

i disagree that collections are an exception, because you may, after future refactoring, need to inherit from an abstract class like Asset. If you've already inherited from List then you can't inherit from Asset (in C# anyway).

[Steven A. Lowe]

there is no 'always' in computer science, there are only trade-offs

[jpaugh]

Absolutely! You could make an even stronger case for it: even the lowly List has extra properties (e.g. length) which has nothing to do with any one of the elements. Therefore, List<Fund> is a "[List] has-a [Fund]" relationship also.