"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.

Answer 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.

Answer 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.

Answer 3

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