Why not inherit from List?

http://stackoverflow.com/questions/21692193/why-not-inherit-from-listt

by rodrigocoelho • 12 years ago

92 74 12 years ago

bilalq2• 12 years ago

So the question basically drills down to why one should use composition instead of inheritance. Most OOP languages only allow inheriting from a single class, and that alone is reason enough to prefer composition in most cases. It's one of the reasons I'm particularly fond of traits/modules.

RyanZAG3• 12 years ago

I don't really know of any OOP language that doesn't have some concept of multiple defined interfaces (eg HasPlayers, HasHomeCity), which is really what you'd want in this case rather than traits or modules.

bilalq2• 12 years ago

The problem with interfaces is that you can't implement any operations within them. Traits and modules do allow for that.

Regardless, compositition makes more sense for this case anyway.

ericHosick• 12 years ago

Also a best known practice:

http://en.wikipedia.org/wiki/Composition_over_inheritance

auvrw3• 12 years ago

although the two aren't mutually exclusive

http://en.wikipedia.org/wiki/Decorator_pattern

ishener• 12 years ago

also, composition is so much more clear and intuitive than abstract inheritance of objects. one should favor simplicity over sophistication always

Roboprog2• 12 years ago

Yep. Team HAS-A list of players, not team IS-A list of players.

While we're at it, "List <? extends Player>" might be a better type for the roster, since it allows players to be subclassed and still fit into the list.

javajosh• 12 years ago

A sports team is a state-machine that evolves in time; a list, or indeed even a value object, doesn't itself express this.

That said, the pithy, smug, common and unenlightening answer is that inheritance breaks encapsulation. But really, that's a terrible reason not to extend a collection class if you really want to. Just remain aware of the trade-offs and do it.

judk2• 12 years ago

Java Lists evolve in time.

danielhunt• 12 years ago

I think his core assumption is wrong in this case, regardless of his feelings towards using List or not:

You count the players on a team, not the team itself: team.count() means nothing Team.players.count() is correct

It would, in fact, be incorrect to even implement a List interface on his Team object

habosa• 12 years ago

I don't think that's correct. He thinks that a team IS a group of players. Just like a list IS a group of items. team.players.count is like list.items.count

But that's a small point, in general I agree that he should not be inheriting from List here.

frou_dh• 12 years ago

The word "interface" isn't in an answer until the 7th one down. The corrupted-OOP straitjacket even suppresses useful terminology!

tolmasky4• 12 years ago

Do you want to be able to pass in Team for every function that currently asks for List<T>? Because that is what you are stating through the act of subclassing. At some point some part of your program may have a List<T>, but actually have a Team.

For starters, most teams I know don't have cloning technology, and thus can't have the same member of a team multiple times, but List<T> absolutely allows this. There are no restrictions on uniqueness in a List<T>. So then you may proceed to override Add() to first check if the team member is already in the team:

    void Add(Player aPlayer)
    {
        if (Contains(aPlayer))
            return;
    
       base.Add(aPlayer);
    }

Wonderful! But now you're a List<T> by name only, because you don't actually behave like a List. You don't follow the most basic postcondition of the API. Every single method that adds an item to a List<T> expects the List<T> to be 1 item larger afterward. So basically, you've created a List<T> that has undefined behavior with every existing function that ever calls Add(), because it doesn't work the way it was originally sold as working, so what is the point of going around calling yourself a List? You are a crash waiting to happen. You are not a List, you are a list manager.

Now is when someone will probably say, no no no. Subclassing isn't the problem. The problem is you didn't subclass the right thing. You should have subclassed Set<T>. Because teams don't have a natural ordering and contain unique players. But now you're just going to run into new problems. Like the fact that you have to check if a player is first in a sane state before adding them:

    void Add(Player aPlayer)
    {
        if (aPlayer.team != null)
            return; // need to be a free agent!

        base.Add(aPlayer);
    }

We can argue whether this should throw, or whether it should do it unconditionally, but the point is that the virtue of needing logic means its not this thing, its something managing this thing. Someone already wrote Set<T> and List<T> code that was almost certainly smarter than you. You wouldn't go poking around their original source to make your program a tiny bit easier to write at risk of ruining other things, so subclassing it is just a way of cheating and only poking around their source only for specific instances, but still causing all the same potential problems for those instances.

Remember, you should ask yourself "Can I guarantee every function that expects a T to behave exactly the same way when I pass a P instead (where P is a subclass of T)?". Almost always the answer is NO, since that's why you subclassed it to begin with! So you shouldn't do it. If the answer is YES, then you've probably only added an ivar or new methods in which case its equivalent to composition. The only thing subclassing gives you over composition is the ability to modify the behavior of existing methods, which breaks contracts with every other part of the code.

RyanZAG3• 12 years ago

Your whole argument seems to base around List<T> allowing for duplicate entries while a Team would not. I don't think this is a very good argument, because you could just extend from Set<T> instead which ensures uniqueness - but would still be the wrong choice.

tolmasky4• 12 years ago

This is a joke right? I literally cover this word for word. I think you read the first paragraph of my argument, stopped reading, rolled your eyes, and decided you understood my "whole argument".

alcari• 12 years ago

[n.b: I'm used to duck typed languages, where you can get away with far more shenanigans.]

"Can I guarantee every function that expects T to behave exactly the same way when I pass P (where P is a subclass of T)". Almost always the answer is NO, that's why you subclassed it to begin with! So you shouldn't do it.

The entire point of subclassing is to be able to answer that question "no". By your logic, we should never subclass anything, because it will behave differently!

It seems to me you're not really trying to argue against subclassing here, but rather against making specific container types subclasses of generic containers types with extra logic (that breaks the container's documented guarantees) added, instead of containing the logic and the container as class attributes.

I'm reminded of the basic inheritance examples that show up all over, where Dog inherits from Animal: this makes sense because a Dog is a type of Animal. A Team is neither a type of List<T> nor a type of Set<T>, so it should not inherit from them. A team can, however, contain a roster represented by a List or Set alongside its other data.

tolmasky4• 12 years ago

The entire point of subclassing is to be able to answer that question "no". By your logic, we should never subclass anything, because it will behave differently!

100% Correct, that is indeed my argument: the very purpose of subclassing is contradictory. Subclassing exists solely to mask the mutation of existing behavior, that is the only feature it adds to composition.

Composition is perfectly capable of ADDING and SUBTRACTING behavior, but to modify behavior it must do so transparently. You can't for example change the behavior of Add, you must call another method that internally calls Add on a child object and makes it explicit to the user code that the behavior is thus different.

There is no point in having a type system if the types become meaningless through subclass manipulation. I make a class T that has method M with postcondition P. People write functions that accept T with these expectations. When you create a subclass of T that modifies the behavior of M, the existing functions can no longer be trusted to behave correctly -- this is just a fact.

It's not at all just about "container classes". We see this broken behavior all the time in UI classes like UITableView extending UIView. UIView theoretically has a publicly mutable subviews array, but it stops being so by certain subclasses. So all of a sudden you have a UIView subclass that can't be passed in as an argument to functions with UIView parameters. This may be obvious to people familiar with the framework, but to novices, it now becomes meaningless to see the parameter UIView. Maybe it will do the right thing, maybe it won't, depends on the subclass. Now you have to go read the documentation (hopefully its documented).

The reason inheritance is taught with ridiculous examples like Dog and Animal (or even worse, Triangle and Shape) is precisely because it is so hard to find legitimate examples. You always end up just overriding things like Speak() (which does nothing in Animal and prints "woof" in Dog). "Good" (re: concrete) examples are usually really convoluted and hard to understand (or end up being basically just interfaces like NSResponder which is 99% empty methods).

Duck typing environments are saner in my opinion because they are really just interfaces. You are not making the strong statement "I am an X" (and thus creating the expectation of static behavior), but instead "I have loose behaviors A,B, and C" (in the same way as interfaces).

deliminator• 12 years ago

"Can I guarantee every function that expects a T to behave exactly the same way when I pass a P instead (where P is a subclass of T)?"

For those who don't know, that's the Liskov Substitution Principle [1]

[1] http://en.wikipedia.org/wiki/Liskov_substitution_principle

SmarterThanYou• 12 years ago

  Someone already wrote Set<T> and List<T> code that was 
  almost certainly smarter than you.

I am so very tired of this weak argument in favor of adopting conventions.

It doesn't persuade me at all. In fact, I see through it for what it really is: An invitation to adhere to someone else's rules.

Whether or not I choose to adhere to List's contract of always incrementing size() by one, after calling add(Object) has nothing to do with whomsoever might be "smarter." It's purely a decision in terms of adhering to the potentially popular expectations of other programmers, or defying them. This is a social requirement, not a technical one.

In other words, you'll catch flak from other developers, who might try to use your code, even if it functions perfectly, for the circumstances it was developed to be used under.

This type of clash of unnecessary, pedantic demands is idomatic to the culture of Java (particularly enterprise Java), much in the way that bizarre, unexpected parsing results are idomatic to PHP, or the hellish nightmare of cross-browser support is idiomatic to JavaScript.

Honestly, if you're not designing an API, and it's not intended for broad use, this sort of rote adherence to established convention can be safely ignored. If your code won't have a very large audience, is well-isolated, tests well, and re-use is not anticipated, who cares?

And listen, don't get me wrong. I'm glad that Java's language specifications are pedantic, strongly typed and designed and written according to properly conceived, well-thought-out contracts. This is the primary benefit of Java over other languages.

On the other hand, if I decide to write a class, while subclassing interfaces from util, while completely ripping the guts out of every method I override, and violating every normal convention the world at large might expect from such a subclass, it has nothing to do with whether the existing interfaces were written by people "smarter" than me. Maybe I just like the semantics of the names of the methods. Now if you'll please excuse me, I have to apply another coat of wax to my ego.

EdwardDiego• 12 years ago

Microsoft did not seal it because sometimes you might want to create a class that has a friendlier name

I expect multiple-language support may have been a stumbling block here but compromising your API (instead of sealing the class, document it as "you shouldn't subclass this") for something that could be done with type aliasing seems like a really bad trade-off. Is the C# using keyword a johnny come lately, or would it not support this functionality?

seanmcdirmid• 12 years ago

Yep:

using MyList = List<MyThing>;

The only limitation is that you can't alias generic types, just fully instantiated ones.

chebum• 12 years ago

If your class users need all the methods and properties List has, you should derive your class from it. If they don't need them, enclose the List and make wrappers for methods your class users actually need.

This is a strict rule, if you write a public API, or any other code that will be used by many people. You may ignore this rule if you have a tiny app and no more than 2 developers. This will save you some time.

For tiny apps, you may also consider choosing another, less strict language. Ruby, JavaScript - anything that allows you to write less code.

fzltrp2• 12 years ago

Strictly speaking you're probably correct. But the problem is that OP is giving as an example a team, without strictly defining the expected behaviour of that class, so everyone starts to imagine his own set of behaviour ovverides, invariants, and so on, and in many cases they are right (the salient point of subclassing is method overriding).

The problem really starts when an invariant supported by a superclass is broken by it subclass. For instance, the idea that a player is unique in a team is obvious, so as said elsewhere in this thread, the Add method, whose invariant is to increment by one the size of the list (because duplicates are allowed, and pretty much no predicate other than equality is applicable to a generic type), would be broken by that Team subclass, and thus any function relying on that implicit behaviour (afaik, c# doesn't implement contracts) would break.

That Liksov substituton principle is tough indeed.

gbog• 12 years ago

Would be interesting to hear what would be the functional stand on this.

In a way a team may not need the players. Maybe teams are just identifiers, as are players, and we have a list of event relating players to teams. Then a function can get these events and compute the current list of players in a given team.

fzltrp2• 12 years ago

Classic functional programming doesn't cover oop: there's no subclassing, thus no issue with using a list to keep your players. Furthermore, pure functional code doesn't mutate, so invariants can't really be broken, unless you meddle with the internal representation, in a way which would confuse the existing codebase to handle lists.

So if you pick list as the implementation detail of your team type, then it will essentially be a list, and may be passed as such to list handling functions without issues. It'll be up to your code to handle the aftermath if your invariants were somehow broken in the process, which would be the proper thing to do. From the outside though, just like for any type, the implementation details shouldn't be exposed. For weakly typed languages, it should be documented to not rely on it.

Edit: I was just handling the original question from an functional stand point. Of course nbouscal solution is much more usable and robust. What would probably happen, if you follow an agile methodology, or some similarly incremental process of development, is that you'd probably start with a list, and as new functionalities would be added, the type would evolve to a tuple or a record including the list. Any function would then have to be updated accordingly. But at least the team type should be made abstract somehow, to hide implementation details.

nbouscal2• 12 years ago

One way of doing it would be to use a record type, one part of which would be the list of players. This is analogous to the composition strategy in OO. You could then manipulate values of that record type using lenses.

The important question is what you actually want to do with this data. The thing that has always seemed crazy to me about OO is how you can have page-long discussions like this one without even talking about what the data is being used for. The notion instead is to "model the real world", which sends you off on a wild goose chase that is almost always unnecessary.

ucarion• 12 years ago

I think this could be boiled down as: List<T> is a data structure. Anything that inherits from List<T> should be a data structure too. So LinkedList<T> could reasonably extend List<T>, but Team should not.

V-2• 12 years ago

Yeah. That's what Eric Lippert called a mechanism vs. a business object. I like this differentiation

nvarsj• 12 years ago

Or use a better language ;-). E.g. in Scala you can use the LinearSeq trait, Ruby the Enumerable mixin to get all the benefits without the drawbacks of Java style subtyping.

laureny• 12 years ago

Or use a better language ;-). E.g. in Scala

You might want to watch Paul Phillips' recent talk:

http://www.youtube.com/watch?v=4jh94gowim0

You will probably start changing your mind about whether Scala is a "better" language. Especially on the collections side.

to get all the benefits without the drawbacks of Java style subtyping.

Actually, the Scala collections have the exact same problems caused by subtyping that Java does (and quite a few more actually, as Paul explains).

goblin89• 12 years ago

I'd rather link to the first answer (http://stackoverflow.com/a/21694054/247441). The “update” section looks like a nice example of how to step back and think about data modeling of this sort.

a football team seems to me to be well modeled as a collection of historical facts such as when a player was recruited, injured, retired, etc

yayitswei• 12 years ago

Reminds me of the tagline for Datomic, a "database of time-based facts".

boomlinde• 12 years ago

I think it's fundamentally wrong to model a team as a list of players. It isn't a list of players, and having a data structure representing the players as a property of the team seems more meaningful in terms of communicating the idea of team members. Even then, the most useful data structure to represent the member players would probably be a set, in my opinion. Then, the whole history of the team could be expressed in terms of simple operations on that set.

alkonaut• 12 years ago

The various SO answers combined sum it up.

- Single inheritance means it's unnatural to inherit from the player list which is just one aspect of a team.

- It's a leak of implementation detail. Tomorrow you may want the team to contain a sorted collection, or a set, or a sorted set.

- It gives an unnatural syntax to team.count vs team.players.count. Again, composition wins in clarity

- You can still expose any part of a collection interface in your Team class, e.g. team.Add(player). The details of what this does should be hidden. Adding an interface like IEnumerable<Player> to the team gives a nice syntax like "foreach(Player p in team)" without breaking encapsulation.

- A list is a simple data structure, a team is not. Extending something to completely change what it is usually means you have an unnatural inheritance. A special list (sorted, cirular...) can extend list in a natural way, a business object should probably "have a" rather than "be a" list.

ollysb2• 12 years ago

> Adding an interface like IEnumerable<Player> to the team gives a nice syntax like "foreach(Player p in team)"

It would be interesting to allow _private_ inheritance, i.e. a class inherits methods from a superclass but they're all private and you need to add interfaces to expose them. That way you could inherit an implementation without leaking it into the public interface.

nitrogen• 12 years ago

C++ does allow private inheritance IIRC, but at that point, why not just use a nember variable?

oneeyedpigeon• 12 years ago

In part, this is a confusion caused by semantics and inherent difficulties with any kind of abstraction. The notion of a 'team' in real life is a very flexible one, and as soon as we try to represent it using a concrete data structure, we're bound to run into problems. The questioner shouldn't be blamed for thinking a team and a list of players are one and the same - there are many real life examples in which the two are used interchangeably. If anything, this highlights the challenge of OOP: real life objects and their relationships are just really difficult to model in a deterministic way.

ap222132• 12 years ago

When I encounter OO beginners, I often have them check out the SOLID principles:

http://en.m.wikipedia.org/wiki/Solid_(object-oriented_design...

I think this person is violating at least 4 of them.

raverbashing2• 12 years ago

I feel OO is so much prone to be misused it's not even funny, exactly because of this.

Or creating a "Human" class inheriting from Body, Arm, Leg, Head

Inheritance also makes TDD a pain in the behind (my opinion) it's not even funny.

ap222132• 12 years ago

OO is a very hard art. It took me a good 10 years to be effective at it. But, I learned in the 90s, when there was a lot less knowledge available. These days, it should be a lot easier - so many good resources.

Anyway, I would love to try other ways of doing it. I see functional programming often sold as the better alternative. However, I've never seen a large code base written entirely in functional language.

Anyone have an examples of large functional programs code bases that are good to learn from?

d04• 12 years ago

Much like most things in life, it takes practice and intelligence.

The negative aspects are primarily because people haven't practiced enough or are being idiots.

TDD is absolutely fine with OO. We have no problems with ~2 million lines of C#. It works pretty well to be honest. If you're finding something hard to test, it's usually broken in some way and usually because concerns aren't separated properly.

d04• 12 years ago

Is it any harder than this?

    class Team {
        List<Player> players = new List<Player>();
        public void AddPlayer(Player player) {
            // rule checks here
            players.add(player);
        }
        public IEnumerable<Player> Players {
            get { return players; }
        }
    }

Covers SOLID, DDD, the lot.

One should never inherit the list. Encapsulate perhaps but the list is there as a fundamental structure and to inherit from it would break the encapsulation of the domain model you are constructing and increase efferent coupling.

robotresearcher• 12 years ago

One useful improvement: the roster of players should be a set, not a list. Duplicated player bugs become impossible.

d04• 12 years ago

Excellent point. HashSet<Player> then.

crystaln• 12 years ago

TLDR: Class hierarchies should only be used for truly hierarchical objects, which is rare. Composition is almost always the correct structure. When in doubt, use composition. You can almost never go wrong this way.

Another way to look at it, by subclassing List, any method that takes a list can also take a Team. That makes no sense. A method that takes a List should take a list of team members.

harunurhan• 12 years ago

I don't think every player is a single property of team. However list of players is. It is more logic to create an object for team which has list of players, name, etc. Although your example doesn't explain your problem, there may be some cases that we need to inherit from List.

gesman• 12 years ago

Just use extension methods to List. Weirdly no one talks about it.

rmrfrmrf• 12 years ago

IMO the easiest way to poke a hole in the argument is to say: ok, now what happens when you want to add the coach of the team? and the owner? Adding them to the Players list would be problematic considering they're not really players. If you tried to rig it anyway, your Count method would return incorrectly, and you'd have to override it to exclude coaches. While we're at it, where are you storing the team's name? A variable name alone isn't going to help you display that info to the end-user.

Granted, none of this matters if the OP's problem domain stays where they have it now. OOP, however, shines when your domain is subject to change and developers are willing to sacrifice terseness for flexibility.

cratermoon• 12 years ago

Is a football team a kind of List? If not, then it's wrong to inherit from List.

Why not inherit from List?

Related Stories