8

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.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
aliensurfer
  • 1,600
  • 3
  • 17
  • 38
  • 1
    Also see [prefer-composition-over-inheritance?](http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance?rq=1) – nawfal Oct 03 '13 at 11:07
  • Does this answer your question? [Prefer composition over inheritance?](https://stackoverflow.com/questions/49002/prefer-composition-over-inheritance) – Melebius May 13 '20 at 08:00

8 Answers8

17

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.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 1
    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` is a "[List] has-a [Fund]" relationship also. – jpaugh Feb 15 '17 at 02:47
8

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.

Steven A. Lowe
  • 60,273
  • 18
  • 132
  • 202
  • Right, had Portfolio been a type of fund, is-a would've made sense. Here portfolio is a list of funds, with a set of properties that apply to all funds. I still don't see how it can't be termed as an is-a. Or is it just how you frame your sentence in this case? – aliensurfer Nov 04 '08 at 20:59
  • @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. – Steven A. Lowe Nov 04 '08 at 22:16
7

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

jonnii
  • 28,019
  • 8
  • 80
  • 108
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.

Robert Wagner
  • 17,515
  • 9
  • 56
  • 72
  • 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.. – baash05 Nov 04 '08 at 21:55
2

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

toolkit
  • 49,809
  • 17
  • 109
  • 135
2

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

Black
  • 5,022
  • 2
  • 22
  • 37
1

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

Charles Bretana
  • 143,358
  • 22
  • 150
  • 216
  • 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. – aliensurfer Nov 04 '08 at 22:13
  • 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 Nov 04 '08 at 22:40
  • 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 Nov 04 '08 at 22:40
  • 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" – Charles Bretana Nov 04 '08 at 22:41
  • this model would work until the business requested the ability to add some Stock, some Bonds, a quantity of Precious Metals, etc., to the portfolio, then it would break. If Portfolio inherited from a collection of Financial Instruments it would still work...until a List became inefficient... – Steven A. Lowe Nov 06 '08 at 05:34
  • 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 Nov 06 '08 at 14:09
  • 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.) – Charles Bretana Nov 06 '08 at 14:15
  • 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 Nov 07 '08 at 04:44
0

IS-A relation ship represents inheritances and HAS-A relation ship represents composition. For above mentioned scenario we prefer composition as PortfolioA has a List and it is not the List type. Inheritances use when Portfolio A is a type of List but here it is not. Hence for this scenario we should prefer Composition.

Sheo Dayal Singh
  • 1,591
  • 19
  • 11