Why I Don’t Inherit from Collection Types

In one of the recent posts in the TDD chess series, I was asked a question that made me sort of stop and muse a little after it was asked. It had to do with whether to define a custom collection type or simply use an out of the box one and my thinking went, “well, I’d use an out of the box one unless there were some compelling reason to build my own.” This got me to thinking about something that had gone the way of the Dodo in my coding, which was to build collection types by inheriting from existing collections or else implementing collection interfaces. I used to do that and now I don’t do that anymore. At some point, it simply stopped happening. But why?

I never read some blog post or book that convinced me this was stupid, nor do I have any recollection of getting burned by this practice. There was no great moment of falling out — just a long-ago cessation that wasn’t a conscious decision, sort of like the point in your 20’s when it stops being a given that you’re going to be out until all hours on a Saturday night. I pondered this here and there for a week or so, and then I figured it out.

TDD happened. Er, well, I started practicing TDD as a matter of course, and, in the time since I started doing that, I never inherited from a collection type. Interesting. So, what’s the relationship?

Well, simply put, the relationship is that inheriting from a collection type just never seems to be the simplest way to get some test passing, and it’s never a compelling refactoring (if I were defining some kind of API library for developers and a custom collection type were a reasonable end-product, I would write one, but not for my own development sake). Inheriting from a collection type is, in fact, a rather speculative piece of coding. You’re defining some type that you want to use and saying “you know, it’d probably be handy if I could also do X, Y, and Z to it later.” But I’ve written my opinion about this type of activity.

Doing this also largely increases the surface area of your class. If I have a type that encapsulates some collection of things and I want to give clients the ability to access these things by a property such as their “Id” then I define a GetById(int) method (or whatever). But if I then say “well, you know what, maybe they want to access these things by position or iterate over them or something, so I’ll just inherit from List of Whatever, and give them all that goodness. But yikes! Now I’m responsible for maintaining a concept of ordering, handling the case of out of bounds indexing, and all sorts of other unpleasantness. So, I can either punt and delegate to the methods on the type that I’m wrapping or else I can get rid of the encapsulation altogether and just cobble additional functionality onto List.

But that’s an icky choice. I’m either coughing up all sorts of extra surface area and delegating it to something I’m wrapping (ugly design) or I’m kind of weirdly violating the SRP by extending some collection type to do domain sorts of things. And I’m doing this counter to what my TDD approach would bubble to the surface anyway. I’d never write speculative code at all. Until some client of mine were using something besides GetById(int), GetById(int) is all it’s getting.

This has led me to wonder if, perhaps, there’s some relationship between the rise of TDD and decoupled design and the adage to favor composition over inheritance. Deep inheritance hierarchies across namespaces, assemblies, and even authors, creates the kind of indirection that makes intention muddy and testing (especially TDD) a chore. I want a class that encapsulates details and provides behavior because I’m hitting that public API with tests to define behavior. I don’t want some class that’s a List for the most part but with other stuff tacked on — I don’t want to unit test the List class from the library at all.

It’s interesting speculation, but at the end of the day, the reason I don’t inherit from collection types is a derivative of the fact that I think doing so is awkward and I’m leerier and leerier of inheritance as time goes on. I really don’t do it because I never find it helpful to do so, tautological as that may seem. Perhaps if you’re like me and you just stop thinking of it as a tool in your tool chest, you won’t miss it.

  • http://thesecretsquad.wordpress.com Peter DiSalvo

    In my (short) experience, TDD definitely helps with better designs. During the refactoring phase of TDD, the thought of “I need to inherit from x” is often not present. If you need to get an item from a collection by its ID, then TDD says your next step should be to create something that “gets by ID”. The simplest implementation of which does not include inheriting a collection type.

    When to use inheritance is often a tough call, but I would equate extending a built-in collection type to “programming by coincidence”. You have the need for a custom collection of something, so you just extend some built-in collection type to start with a completely functioning collection. Problem solved. Except, when you need to modify it you have to tread carefully not to dislodge any of the gears of the parent collection type, e.g., “I’ll just override x method for this new functionality”, and now you’re at risk of breaking something. This is also a problem of inheriting from deep within a hierarchy.

    Implementing a collection type interface can be a good idea, but only if you’re actually trying to build a new implementation of that collection. I struggled for a long time with the question of when to use inheritance vs composition. The conclusion I came to is that inheritance should be intentional, not incidental. Inheritance hierarchies should be designed with inheritance in mind. Classes shouldn’t just extend from something to acquire some functionality. Built-in interface types, like IComparable are an exception, because they are designed for inheritance. Sticking to these guidelines has helped me make, what I believe, better decisions with inheritance.

  • http://www.daedtech.com/blog Erik Dietrich

    For me, inheritance versus composition (specifically via interfaces) is aided by the old “behaves like” (interface) versus “is a” (inheritance) adage. Since first learning OOP principles some 15 years ago, I’ve known about that rule of thumb, but really listening to it and thinking in terms of the problem domain is a help. For example, “truck is a vehicle” seems to define a relationship that lends itself to inheritance in OOP modeling. But “ViewModel is a ViewModelBase?” Well, maybe, but what on Earth is a “ViewModelBase”? That’s not a thing. It’s not an abstraction. It’s an inheritance deepening convention, and the base class no doubt provides a number of behaviors that inheritors could instead opt into via composition and dependencies ala carte.

    I definitely agree that the focus on testability helps in this regard. I mean, a generalized base class (or, in some cases with deep hierarchies, classes) drag that functionality into all sorts of test classes where the pain of the redundancy is exposed. Do I have to test “ViewModelBase” functionality in each and every one of the ViewModels in my system? Now I have to choose between thoroughness and having tests where they belong and avoiding brittleness and redundancy.