"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, usableness, and what have you? I can still access my funds either way, albeit with a small syntactical change.

Answer 1

The first one, becuase you should always favour composition over inheritance when you can.

Answer 2

I would go with option (1) - composition, since you may eventually have attributes specific to the portfolio, rather than the funds.

Answer 3

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

Answer 4

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 5

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.

Answer 6

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 7

I will differ with what appears to be the common opinion. In this case I think a portfolio is very little more than a collection of funds... By using inheritance you allow the use of multiple constructors, as in

public Portfolio(CLient client) {};
public Portfolio(Branch branch, bool Active, decimal valueThreshold)
{
    // code to populate collection with all active portfolios at the specified branch whose total vlaue exceeds specified threshold 
}

and indexers as in:

public Fund this[int fundId] { get { return this.fundList[fundId]; } }

etc. etc.

if you want to be able to treat variables of type Portfolio as a collection of funds, with the associated syntax, then this is the better approach.

Portfolio BobsPortfolio = new Portfolio(Bob); 

foreach (Fund fund in BobsPortfolio)
{
    fund.SendStatement();
}

or stuff like that