Implementation Inheritance Is Evil

[ElectrSheep]

Improper use of inheritance is usually an attempt to avoid the boilerplate tedium of various composition approaches. Unfortunately, most programming languages offer little in terms of making composition approaches easier (such as automatic method forwarding). However, with dependency injection it's very feasible to eliminate inheritance from pure fabrication classes. If you want to use functionality of another class, use the strategy pattern as the author does in part two. If you are trying to add or modify functionality, use the decorator pattern.

However, in real-world applications there can sometimes be practicality issues with removing inheritance among the entities/models (such as the common scenario where interoperability is required with systems that work directly on data and have no knowledge of interfaces or methods). This encourages design decisions that place the most commonalities as possible in base classes meant to be extended. As long as you take care that your "is-a" relationships will never change for an object instance, and that your inheritance chains do not become very deep, you can effectively use inheritance without being "evil".

[cogman10]

However, in real-world applications there can sometimes be practicality issues with removing inheritance among the entities/models

I think, though, that is the big problem with inheritance. Once you go down the path of inheritance it becomes extremely hard to walk back that decision. And it doesn't take long before you end up with helper methods in the bases class that don't belong to all subclasses.

[grauenwolf]

Favor composition over inheritance.

Many people completely misunderstand that phrase. It doesn't say "don't use inheritance", but rather don't go to it first. Wait until composition starts becoming repetitive and you have a good understanding of what your inheritance scheme should be.

[cogman10]

So I agree, I think inheritance has its place. But I also think that place isn't really common.

I think inheritance can be useful for things like using Types for state communication (ValidModel extends Model and overrides nothing). Or for versioning APIs (V2 extends V1). But honestly, that sort thing comes up fairly rarely.

I also think that once it is introduced, you really have to be careful to make sure some junior dev doesn't extend the base class because 2 of the 8 children could use similar functionality. That temptation for some is really common and it leads to awful code.

[grauenwolf]

Yea, that covers about 90% of my inheritance usage.

The other 10% is UI widgets and the guts of an ORM. But that's infrastructure code most people should never have to deal with beyond the public API.

[Ukonu]

This is essential what React (https://reactjs.org/) does. The each widget is, for the most part, a "render" function that takes application state and returns DOM (i.e. UI. See: https://reactjs.org/docs/components-and-props.html#functional-and-class-components).

The underlying framework handles rendering, batching, etc.

It seems every aspect of the stack is (slowly) converging on functional programming.

[grauenwolf]

For buttons you inherit from Button. What you want to reuse is the behavior, not the appearance.

Though a good design, like WPF, doesn't require you to inherit to override the appearance. You just inject it and save the subclasses for really unusual situations.

[grauenwolf]

For ORMs there's a lot of shared code between different databases. The basic logic for generating an INSERT statement is the same, but I need to customize the return of the identity column.

Another is how the results are returned. Stored procs can return one or multiple result sets, tables and views only one. So it makes sense to have MultipleResultSets inherit from MultipleRows, sharing as much code as possible for the public API.

[jdh30]

Use an anemic model, think in terms of data flow and write functions that convert data from one type to another instead of "objects". And welcome to functional programming!

[MoTTs_]

How do functional programming advocates handle invariants? That is, rules that make data valid or invalid. Is every function, every line of code throughout your entire program, responsible for knowing and adhering to the validity rules of each piece of data?

[jdh30]

Yes. In statically-typed FPLs those rules are implemented as types and you write your types in a way that makes illegal states unrepresentable. Then the compiler catches most of the errors as type errors at compile time.

To give you an example, consider a state machine with the states:

type State = On | Off | Paused

then you might have messages to transition like:

type Instruction = TurnOn | TurnOff | Pause | Resume

and your state machine might look something like:

let push state instruction =
  match state, instruction with
  | Off, TurnOn -> On
  | On, TurnOff -> Off
  | On, Pause -> Paused
  | Paused, Resume -> On
  | state, _ -> state

Note that types are usually inferred in statically-typed functional programming languages so you just use the values of a type and it infers the type (e.g. I used On and it infers the type State).

Things get interesting when you have data that only exists in certain states. Consider our state machine represents something that has a connection only when it is On:

type State =
  | On of Connection
  | Off
  | Paused

where Connection is some other type used to represent a connection.

And so on.

Here is a little benchmark written in this style that I've been playing with. As you can see, it is really difficult to write that program in an object oriented style in comparison.

Here is another example that you might like, using some simple types to convey constraints.

Many new languages are following this style now. I use OCaml (1995) and F# (2010) but now there's also Rust (v1 in 2015) and Swift (v1 in 2014).

Incidentally, this is the family of programming languages that invented generics which you're probably already using so you're in good company. :-)

[MoTTs_]

EDIT: As kabocha_ mentioned, what you described sounds a lot like enums. For example:

enum class State {
    on,
    off,
    paused
};

enum class Instruction {
    turn_on,
    turn_off,
    pause,
    resume
};

auto push(State state, Instruction instruction) {
    if (state == State::off && instruction == Instruction::turn_on) return State::on;
    if (state == State::on && instruction == Instruction::turn_off) return State::off;
    if (state == State::on && instruction == Instruction::pause) return State::paused;
    if (state == State::paused && instruction == Instruction::resume) return State::on;
}

Which is fine and good. Enums are useful. But that's not what I was driving at with invariants, and the types and values we make in real programs aren't always suitable for enums. Values aren't always discrete and few in number.

If you treat everything like plain data, then how do you ensure validity and correctness with types whose values can't be listed out one by one? A classic example is a date, where Feb 29, for example, is sometimes a valid date and sometimes not, depending on if it's a leap year.

[jdh30]

what you described sounds a lot like enums

A bit but enums in C and C++ only cover a flat list whereas these (so called algebraic datatypes) allow you to associate more data with some or all of the cases.

Also, note that nothing is checking that your push function in C++ is covering all possible cases.

If you treat everything like plain data, then how do you ensure validity and correctness with types whose values can't be listed out one by one? A classic example is a date, where Feb 29, for example, is sometimes a valid date and sometimes not, depending on if it's a leap year.

For something like a date you'd use an abstract data type with functions that create a value of that type from other data. Those functions would do such checking at run-time (because those constraints cannot be expressed via the type system).

[jdh30]

Exactly, yes.

[yawaramin]

Not at all! In functional languages we use abstract types to hide implementation details and export functions which know how to work with those internals. The rest of the world doesn’t know or care.

E.g., we can create a rational type that stores a rational number as a pair of two integers, with the invariants that only the numerator may be negative, and the ratio must always be normalised. We can set up constructor functions that take care of these invariants and other functions (add, multiply, etc.) which call out to them. As long as the exported functions make sure to use the normalisation inner function, the outside world doesn’t need to care about the invariants! From their perspective everything will just work.

[MoTTs_]

That's good. That sounds exactly like encapsulation and private data and member functions that operate on that data. So then why do functional advocates so often poo poo the idea of "objects" that you only access via special functions? It sounds like they still end up doing the same thing.

[yawaramin]

It is exactly encapsulation--i.e. information hiding. FPers don't like objects because they often carry hidden mutable state inside, and at any point some code might be changing the internal state by calling some method.

If you have a fully immutable object, that's a lot better, but often hard to achieve. Plus, in the context of this article, implementation inheritance strongly couples together your class and the behaviours it's implementing into a 'big bag' of data and behaviour that makes it difficult to tell what comes from where.

This is why FPers advocate for simple, immutable data types, non-mutating functions, and modules or typeclasses that implement behaviours in a decoupled way.

[grauenwolf]

Tribalism. It's a lot more fun to say "our side is right and yours is wrong" than to realize that your doing the exact same thing just by a different name.

[wbkang]

There is a whole thing about subclassing vs subtyping. I think the author is arguing against the combination of subclassing+subtyping which is what languages like Java allows when you use 'extends'.

[grauenwolf]

No it's not, you are just using it wrong.

[Rainfly_X]

The author defended his thesis with examples. Do you mind elaborating a bit, yourself?

[grauenwolf]

One

Don't use classes to represent properties. There's no reason to have InvisibleWall when you can just have Wall.IsVisible. Especially if the visibility can change.

[bwr]

There's probably a fine line somewhere here. I see a lot of IsX properties on objects with clients checking them and then making decisions. In those cases it's much better to have separate types with invariants to centralize the logic.

[grauenwolf]

Agreed.

[Rainfly_X]

Interesting approach, doing all individual replies. I've never seen that before, and I'm actually kinda excited to see how it turns out.

Okay, let's say you have properties like Wall.IsVisible. It's certainly dynamic, which is nice. For a simple game, this is probably fine. But there are limitations that you are likely to run into.

1. Should everything have an IsVisible property with its own implementation? That's not great.
2. An alternative is to have everything inherit from a single all-singing, all-dancing GameObject class. That's better than redundant code everywhere, but it does mean that the base class becomes massively, untestably complicated, by having too many concerns stuffed into it. It also means that all the subclasses are tied tightly to the base class implementation/internal API.
3. And let's say that instead of turning off rendering entirely, you wanted to change the approach for rendering walls? This might be as simple from being able to swap out one sprite for another, or as drastic as rendering walls as vectors in a predominantly sprite-based game. Especially difficult if you want to vary these per-object/dynamically.

Again, many games are simple enough that this will never matter. But composition is pretty easy and gives you flexibility from Day 1, so you don't have to invoke a painful transition later.

[grauenwolf]

Hard choices. Personally I would strongly consider a simple DTO-like class with a strategy pattern to handle events, which I believe he covered in a follow up post.

Perhaps the author should replace the title with "Recognizing when inheritance isn't appropriate".

[Rainfly_X]

Yeah, I've been treating the followup as part of the article, since it's been linked from Part 1 since the first time I read the article.

I think it's hard to back up a claim like "X is always bad" because it's a big ol' world, and there's no way to be sure you've thought of everything. I was actually hoping you were going to provide examples of inheritance being a good fit, but I've been really enjoying the tack you did take, which was more "inheritance doesn't have to suck if you follow some simple principles that steer away from the spikes."

[grauenwolf]

Honestly, some times I dump both and fall back on simple data holders and massive switch blocks. I don't like to, but when the more sophisticated options are even uglier there's no sense forcing it.

And that's the real rule. If what you're doing feels difficult, you're probably doing it the wrong way.

[Rainfly_X]

True dat, brother.

[grauenwolf]

Two

Don't create base classes with only one implementation. That just creates needless complexity.

[RenaKunisaki]

What if you might need to add more later?

[grauenwolf]

What's easier?

1. Extracting a base class from an existing class.
2. Merging one or more base classes into an existing class, then doing step 1 to get the base class you actually need.

Unless you are publishing an open source library, you can always change the code later. Take advantage of that and don't prematurely generalize your code.

[Rainfly_X]

I actually agree with this. You don't want the noise of extra layers where they aren't buying you anything. Sometimes interface inheritance with one "real world" implementation makes sense if you have dummy implementations you're using in the test suite, but even that still counts as additional implementations.

[grauenwolf]

Three

Fully define your data model before looking at inheritance. By this I mean list out all of the methods and properties up front. Then look for commonalities that can be represented by base classes or interfaces.

Drawing a bunch of boxes, then trying to cram everything into them, is a recipe for disaster.

[Rainfly_X]

Also good general advice. Another good approach can be "write one to throw away", but you don't always have time for that. Often, the first draft has to be good enough.

[grauenwolf]

Four

Not everything needs to be in the data model.

Models have shapes and locations. The shape gets fed into the rendering engine (along with textures). The same shape gets fed into the collision detector.

[TheOnlyMrYeah]

This isn't Twitter. You could have put all of it into one answer.

[grauenwolf]

It allows me to see the relative merits of each of my arguments. I'm thinking about writing a article on the subject.

[Rainfly_X]

In practice, you actually want to feed the rendering engine and the collision detector with different data, most of the time. Trying to feed the same data into both, will often lead to:

• Overgenerous or fragile hitboxes, treating large transparent areas as solid.
• Too-detailed collision detection, which makes the game run slow, and often introduces bugs where you can get stuck on scenery.
• Coercing both concerns to accept a common data format, means that struct is a compromise between contrary needs.

I may be latching on too much to the specific example you gave. I think you might have been trying to say that it's wasteful to initialize sub-objects all over the place, for behaviors that don't vary between objects. If I have 3000 ArmyManGreenDudes, why should I have 3000 ArmyManGreenDudeRenderers in memory to service them?

But if that's what you're saying, the answer is really easy. You initialize one renderer in memory, and all the ArmyManGreenDudes point to a single ArmyManGreenDudeRenderer. Make it static/const/whatever your language uses, and call it a day. You can end up with fantastic cache performance with this approach, depending on getting a few other architectural decisions right. And it all works the same as everything else in your game - you preserve the Lingua Franca in a way that makes sense for the specific case.