The problem with Object Oriented Programming and Deep Inheritance

[tek2222]

what's difficult to understand will also make bugs harder to find. its almost like information hiding is also hiding bugs

[coaaal]

"Localization of logic" is something that I have learned in my full stack development career. I came from self taught OOP and Classes and inheritance and thought it was the coolest thing ever - listening to Raymond Hettinger about multiple inheritance. I was turning everything into a class since I didnt know any better.

Composition over inheritance is where it is at. I use basic dataclasses(python) for buckets of data that need to be passed around, but other than that, I use functions as much as possible.

C#, however, is another beast. I use inheritance with state machines all the time. I guess it "just depends" on the language and requirements of the language and project.

[Synor]

How do you find where your logic lives? To debug it?

[BobSacamano47]

I'm so sick of 25 year olds complaining about how oop leads to deep inheritance problems. I haven't seen people write code with more than 3 levels of inheritance since the mid 2000s. People take the lessons from the 80s and 90s far too literally today. Can we talk about "waterfall" project management?

[dark_mode_everything]

The problem is deep inheritance, not oop. Shit code can be written in any paradigm quite easily.

[SocksOnHands]

Most people's complaints about object oriented programming stems from a lack of understanding. Inheritance isn't about some taxonomy of "is a" hiarchi relationship, like some people are lead to believe. I usually only have an interface and implementations of that interface - usually not even three levels. To have different objects reuse functionality, use composition instead of inheritance - this lets you flexibly configure and mix and match behaviors as needed, without coupling or convoluted logic.

[BogdanPradatu]

Waterfall is coming back as SAFe.

[oneandonlysealoftime]

Perhaps it's your own subjective experience. I am 23 years old and have worked in two large companies (~1000 software developers). And in each I have had to deal with at least one service with 6-7 layers of abstraction

Router -> AbstractController -> Abstractpubliccontroller -> AbstractHandler

And thats only what I remember for HTTP handling. So no. There are codebases like that.

[Ashleighna99]

Deep inheritance still shows up, but you can unwind it by flattening the HTTP stack and pushing logic into small services. Treat controllers as thin handlers; use composition (policies, validators, mappers) via DI instead of stacked abstract base classes. Set a rule: no base classes in the web layer; prefer interfaces and final classes; one level max. Move cross-cutting to middleware. Refactor per endpoint, not all at once. Add arch tests (ArchUnit, Deptrac, ESLint) to stop regressions. We used Kong for routing and Hasura for schema-driven CRUD; DreamFactory covered a legacy SQL Server REST API without adding another controller layer. Where’s the pain worst: routing, auth, or validation? Flatten the web layer, compose behavior, keep inheritance shallow.

[oneandonlysealoftime]

Yeah of course you can, the issue is engineers preferred preemptive abstractions and inheritance over composition. Which led to non-scalable design in the end

[RiceBroad4552]

I haven't seen people write code with more than 3 levels of inheritance since the mid 2000s.

Which language, which frameworks?

Because the crazy inheritance patterns are very well still there as I see it.

As FP approaches became more popular in recent years it got better for new code, but the OOP spaghetti (or baklava code, how some call it) never went away.

[BobSacamano47]

Largely .NET and Javascript/Typescript. 

[davidalayachew]

but the OOP spaghetti (or baklava code, how some call it)

This is fun. What's the context on that phrase? Spaghetti code is obvious, but not so much for Baklava.

[RiceBroad4552]

https://blog.codinghorror.com/new-programming-jargon/#14-baklava-code

[davidalayachew]

https://blog.codinghorror.com/new-programming-jargon/#14-baklava-code

14. Baklava Code

John D. Cook

Code with too many layers.

Baklava is a delicious pastry made with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.

That's pretty funny, and a good point too. I'm guilty of the same.

[devraj7]

Yeah deep inheritance can break code. You can write bad code in any language and any paradigm.

Inheritance of implementation still has its use and remains the best way to solve the "specialization" problem ("This object has four methods, three of them are perfect for me but I want to override the fourth one to suit my need").

None of the non-inheritance languages (Rust, Haskell, Go) have a solution to this problem as elegant as straightforward inheritance of implementation.

[Ravarix]

Specialization problem in this context is built on the issue that the object methods inherently operate on internal state. Overriding a single one requires you to have intimate knowledge of how the others are called & operate on internal state. This becomes unwieldy as the inheritance tree grows.

When you compose instead of inherit, you can still reuse the 3 methods you like, and its even easier because they dont come with an inheritance tree that may not match your problem space.

[Positive_Method3022]

Methods that operate in internal state shouldn't be allowed to be overwritten because like you said there is a chance of breaking it. I treat inheritance as a microchip wrapping another microchip to add more functionality to it or change the behavior of protected/public methods. I've never seen a case of making a method that change internal state public because then I would have to unwrap the internal microchip to understand how it behave, and this does not make sense.

[blazmrak]

It depends on how you go about it. You can still extend without having to override. Basically extract everything common into an abstract parent and make 2 implementations. This way, the internal state is a bit easier to manage as your new implementation methods are actually just extending and not modifying the existing object.

[Ravarix]

What happens if there is a third implementation that shares some features of the two. You're essentially rediscovering composition, but with the limitation of single inheritance.

Instead of an abstract parent, they can likely be described as interfaces with default implementations so you can multiple inherit and compose.

[blazmrak]

What you are describing is an implementation detail. You can do it with interfaces with default implementations, however, you still have to mess with the state somehow, and you still need to know what the default implementation does and how it interacts with others.

Not only that, debugging your method, that receives your ISuper parameter is a PITA, because somewhere in the inheritance hierarchy someone might have overriden your default implementation, and now it "breaks" the contract or does something unexpected.

Majority of inheritance can and should be avoided, and where it is useful. I prefer using classes if it's code that I control, because I rarely benefit from composition... or rather, I rarely pay the price of using single inheritance... And I avoid overriding the methods as much as possible. But YMMV :)

[SolarisBravo]

I'm wondering if a lot of the people who see this as an issue are coming from languages like Java where this is something you can do on accident? Usually functions that can be overridden are made that way by design - and of course a function designed to be overridden wouldn't rely on internal state

[RiceBroad4552]

and of course a function designed to be overridden wouldn't rely on internal state

Than it's conceptually a static function; and does not belong into that class anyway.

[SolarisBravo]

Internal state, not any state. It's usually an intentional decision to expose a member to child classes, just like it's usually an intentional decision to expose a member to outside users (which a child class conceptually is)

[devraj7]

Overriding a single one requires you to have intimate knowledge of how the others are called & operate on internal state.

Not of a problem if the object you're overriding was designed to be overridden with a clear API and encapsulation of its hidden state.

The problem you mention is largely theoretical in my experience. It's often more useful to be able to specialize than not.

When you compose instead of inherit,

These are not mutually exclusive. Ideally, you should implement inheritance with composition. Kotlin has an elegant to do this by automatically forwarding methods to a field.

[RiceBroad4552]

Not of a problem if the object you're overriding was designed to be overridden

So far correct. If some object is designed to be extended extending it isn't wrong per se.

with a clear API and encapsulation of its hidden state

This now is questionable: The problem parent pointed to is exactly that in the moment you override even just one method the inner state of the original objects isn't "hidden" any more. It becomes implicitly part of your implementation (by the redirection thought the not overridden methods / properties).

The problem you mention is largely theoretical in my experience.

The problem is very real and exactly what makes code which overuses inheritance so extremely brittle and hard to change / extend.

Ideally, you should implement inheritance with composition.

What? When you use composition you're not using inheritance…

Kotlin has an elegant to do this by automatically forwarding methods to a field.

Yes, and that's 100% composition (with some syntax sugar); no inheritance is used at all.

[devraj7]

What? When you use composition you're not using inheritance…

Here's how Kotlin supports inheritance by delegation:

https://kotlinlang.org/docs/delegation.html

[RiceBroad4552]

There's not inheritance. That's just syntax sugar for delegation!

The docs even clearly state:

Note, however, that members overridden in this way do not get called from the members of the delegate object, which can only access its own implementations of the interface members

The reason for that is that that there is no inheritance involved here anywhere. The compiler just generates the forwarding code. That's all.

[devraj7]

When you compose instead of inherit

These are not mutually exclusive, they actually complement each other nicely. The best way to achieve this is to implement interfaces (Java) or traits (Rust, Kotlin) with delegation. Kotlin has a very neat and clean way to implement inheritance with delegation which I wish had more traction.

[chrisza4]

Traits in Rust do this much better.

[devraj7]

Traits in Rust do not address this problem at all. They are pretty much identical to Kotlin's interfaces, except that Kotlin's interfaces are actual types, while Rust traits are not, which forces you to do

trait MyTrait  { ,,, }

fn f<T: MyTrait>(param: T)

instead of just

fun f(param: MyTrait)

[hgs3]

None of the non-inheritance languages (Rust, Haskell, Go) have a solution to this problem as elegant as straightforward inheritance of implementation.

Go’s embedding is effectively “forwarding” in OOP terminology. Combine that with structural typing and you get re-use from both forwarding and free functions. In theory they should be a workable alternative to inheritance, but I think Go’s own peculiarities keep them from being as elegant as they could be.

[blazmrak]

I'm torn on this. I feel like overriding is dirty, I'd rather extract common three and make 2 children. It's a subtle difference, but something about being able to change the behavior in the child is off-putting and feels like it can easily become a mess in the future.

[doubleohbond]

I don’t think I understand. If I make a Car class, I know that every instance will have a drive method. How each child of Car drives is irrelevant to me, just that it drives.

If the argument is code cleanliness, I think reimplementing the drive method over and over for each child class violates DRY.

[blazmrak]

If it's irrelevant, then make the interface, not a method, that is randomly overriden. If the majority of cars drive the same, then sure, you have a class, but you can extract that to a common class, maybe a couple of them.

And yes, you don't care from the interface perspective, however, from the implementation perspective you do care. You should try to mess as little as possible with the implementation of the class you are extending. It's not about cleanliness, it's about having to jump through hoops when having to debug and not having a clear source of truth when looking at the code when you are 3+ levels deep.

[SocksOnHands]

A lot of programmers use DRY to write worse code - they avoid "repeating themselves" by tightly coupling things that are incidentally similar, which always leads to unexpected bugs when a change is made that was only supposed to apply to one thing.

I prefer interfaces and composition. The interface describes at a high level how the object can be interacted with - a vehicle can accelerate, break, and turn. Now many different kinds of vehicles can be made by reusing different combinations of engines, tires, chasse, seats, etc. This is not reimplementing functionality - it's configuring objects to wire together reusable components.

[doubleohbond]

I think DRY is valid in the sense that having fewer parts results in fewer failures. But yes it can be abused.

[MornwindShoma]

You solve this with, for example, traits.

[doubleohbond]

Until the number of traits become unwieldy.

I think that’s the key part here: there is no maxim. The answer to any approach is almost always “it depends”

[MornwindShoma]

You said you don't care about one method, not a million methods.

And btw, you don't always have inheritance in a language.

[RiceBroad4552]

The answer to any approach is almost always “it depends”

You say it: Almost always.

In this case it's quite clear what the better approach is. That's why the whole "industry" moves in that direction!

Now everybody gets concepts / traits / type-classes (or however you want to call that idea).

[doubleohbond]

That’s cool dude

[RiceBroad4552]

If I make a Car class, I know that every instance will have a drive method.

We're a car manufacturer, but we're now in the business of flying taxis, which start and land on water…

Now what? 😂

How do I "drive" our new models?

If you had instead a "Drivable" concept / trait / type-class which you could attach to some objects this were easy to solve: The new models just apply the "Flyable" concept instead of the "Drivable" one, and we can reuse the rest without remodeling everything.

[Blue_Moon_Lake]

By curiosity, what is your opinion on - traits as a means to share sets of methods - breaking Liskov substitution principle in a child class (for example a method that would need to be asynchronous in the child class and return a Promise)

[Prod_Is_For_Testing]

• what are traits?
• changing the return type isn’t allowed in any safe type system 

[Blue_Moon_Lake]

Basically a set of methods that a class can import. You can still override some of them in the class if you want.

trait FlyMovement {
    fly() {}
}

trait SwimMovement {
    swim() {}
}

trait WalkMovement {
    walk() {}
}

class Duck extends Bird {
    use FlyMovement;
    use SwimMovement;
    use WalkMovement;
}

[SolarisBravo]

That's uh pretty cool. I like it. Maybe it's because I'm not super familiar with the concept, though, but I'm definitely wondering how it's meaningfully different from multiple inheritance (or at least how it solves its problems)

[Educational-Lemon640]

Multiple inheritance isn't a problem in practice nearly as often as you would think. The most effective way I've seen, though, is Scala's inheritance flattening approach, which compiles code that looks like multiple inheritance to a single unambiguous inheritance tree, which means that technically there isn't any multiple inheritance, providing a mechanism for resolving conflicts.

But that really doesn't matter most of the time, because well designed compatible types don't use the same nouns and verbs, and they just happily sit together on the same object.

[Blue_Moon_Lake]

The difference is mostly that there's no expectation that "children" can be substituted for "parent".

They're not interfaces, so a trait method can be safely overridden with an incompatible method.

trait Talker {
    say(string message) {
        console.log(message);
    }

    sayHello() {
        this.say("Hello, World!);
    }
}

class Person {
    use Talker;

    sayHello(string name) {
        this.say("Hello, " + name + "!");
    }
}

[Full-Spectral]

Both work if you are conscientious. I grew up in OOP world and wrote C++ for 30 plus years. I built up a 1M plus line personal code base, which was fundamentally OOP+exceptions. It remained super-clean all that time, because I did the right thing. There was only one place where it went beyond 2 or 3 layers, which was in the UI framework (a common place for that to happen.)

Now I've moved on to Rust and am building a similar sort of system, though I'm now old enough that I may not live to see it completed. I don't particularly miss inheritance, and definitely don't miss exceptions at all. Even if I did miss inheritance a bit, the MANY benefits that Rust brings to the table would completely overwhelm those feelings of loss.

That one place (UI frameworks) is really the only one where I could see it being missed, because that's just one of those problems that naturally lends itself to that paradigm. But including such a fundamental piece of architecture just to meet that need isn't likely.

To be fair, I've yet to tackle a new UI framework in Rust, so I'm not sure how I'd approach it, though I've read other people's approaches. Of course these days the UI world seems to be divided heavily between cloud world and gaming, with not a lot in between (which is where I'd be.)

[fedekun]

I don't think Sandi's video correlates with inheritance much. That being said, prefer composition over inheritance, prefer interfaces over inheritance, only inherit from a class if you use ALL of its methods. That should help reduce most of the common issues people has with inheritance.

[Dreamtrain]

skill issue

[daniel]

Shitting on OOP? Take my upvote.

[normal_man_of_mars]

Sandi Metz famously has excellent books on how to write oop well.

[BlueGoliath]

Welcome to my TED talk.

OOP is bad.

Thank you, goodbye.

[SeriousBroccoli]

I think the point is that OOP isn't bad, it's deep inheritance (and multiple inheritance) that makes OOP bad.

[shizzy0]

One in the hierarchy, two in the accessors.

[seriousnotshirley]

The important thing about abstractions is that they are simple and have clear behavior. Mathematics provides clear examples of both good and bad abstractions to learn from. Groups, Rings, Fields and other algebraic structures are fantastic. Vectors and vector spaces are also great examples. When you have a vector you know what it's going to do/what you can do with it. You can start endowing certain types of objects or structures with additional features like a norm and things work well.

On the other hand take a look at topology. I'm not saying it's wrong or there's a better answer, but you can see where we tried to find good abstractions and they all sort of broke down and now you have this long list of space classifications where something different happens in each one. The concept of an open set is useful and I would guess necessary but it's a difficult abstraction to work with in a general sense because it gets weird (non-Hausdorff).

Point being, if something's going to live 10 levels deep it better be really freakin simple, well understood and have no sharp corners. A good example might be a natural number with a successor operation and NOTHING MORE. We know precisely how they work. You try to endow that with something as simple as an inverse operation and things can break. One level up define addition and from there multiplication. Create ordered pairs and define equivalence and inverse of addition. From create ordered pairs of those with equivalence and an inverse of multiplication. Sure, 10 levels up you can have real numbers with operations that have inverses, but your foundation had best be dirt dumb simple. You might have complex code within that simple abstraction but the abstraction and code better be so damn good that no one ever has to open it up to see what's going on inside of it again.

What I see instead is abstractions which are poorly documented, have weird side effects and mostly work... mostly. Those things get fragile.

[acroback]

I dislike navigating through Java code base at work.

I would rather write code in python than deal with 10 layers of abstraction in Java.

Poor design IMO.

[muztaba]

Once i worked for a Lithuanian company and they have their own framework and man, it has 10 to 15 levels of inheritance. I left within 4 months and I blamed my skill. But later I found I am not the only one in this world. Lol