Inheritance is the most misused capability of OOP which programmers think makes their code look smart, but most of the time just makes a giant fucking mess.
I’ve moved away from Classes in general unless it truly makes code more streamlined. The main language I was taught in highschool was Java and it’s just so liberating not needing to turn everything into an object.
But recently I’ve used a Class specifically for Inheritance. I’m making an extension to Pytorch and almost everything in Pytorch uses Tensors as a medium. I made a new kind of tensor that inherits the Tensor class to add specific restrictions on how it behaves. Because of this, this new tensor object can be used with any of the preexisting pytorch functions while also validating the results, reverting to a Tensor if it becomes invalid.
Even in this situation though, all my programming logic rests in it’s own static functions, and the class contains functions that call the static version. The only actual logic the inherited object handles is validating the data.
Because of this, I feel like inheritance is most useful when you’re inheriting someone else’s code to make it compatible with their library. I don’t think I’ll ever inherit my own objects because that’s how you end up with Java.
Its the best/worst thing about OOP no matter what language.
We had a rule at work that if you are 3 levels or more down an inheritance tree, then you are too far. The cognitive load is just too much, plus everything stops making sense.
One level can be great (MVC all have great conventions, MCP as well). Two can be pushing it (Strategy pattern when you have physical devices and cant be connected all the time, Certain kinds of business logic that repeat hundreds of times, etc…) But even there you are kinda pushing it.
I need code that I can look at a month from now and know WTF is happening. And sometimes its better to have less DRY and more comprehension. Or maybe im just a forever mediocre dev and dont see the “light”. I dunno.
composition can help with all of that. factories, strategies, injections are all composition patterns that work fine.
business logic that repeats? extract it to it’s own thing (class, function, etc) and pass it as a param to the supposed childs.
mvc? controllers don’t need to extend anything, just have them accept the framework through the constructor and request and response as args. views? same. models? perhaps only if doing an active record, but a repo pattern with plain objects is a good pattern too.
I never seen a clean inheritance implementation for a decently sized problem. it mostly works for tiny ones.
Depends on what you mean by “basically a class”. If you mean inheritance, overriding, and more generally class/inheritance based polymorphism, no, it does not. Those require dynamic dispatch, which Go does not have (for concrete types, which is what we’re talking about here).
This is exactly how I feel too. A little bit of repetition is totally worth it, versus having inappropriate coupling, or code that jumps in and out of parent/child classes everywhere so you can hardly keep it in your head what’s going on.
I freely accept that I AM a mediocre dev, but if that lends me to prefer code that is comprehensible and maintainable then I think being mediocre is doing my team a favour, honestly.
I can definitely respect a limited approach. I personally don’t find any benefit from it. Anecdotally, I’ve become much more productive since switching from OOP style C++, to just straight C. I think a lot of that comes from the boilerplate and ceremony required to make it do the thing, but in C, you just do the thing.
I also think even using objects tends to encourage poorer design choices by thinking in terms of individual items (and their lifetimes) which is enforced by the constructor/destructor model. As opposed to thinking in terms of groups of items which leads to simpler and safer code.
PTSD flashbacks to the codebase I started on in 2008 which had… I don’t even remember. Like six or seven levels. Fucking nightmare. I did a printout of the analysis Doxygen gave me and it ended up as a 4x3 meters poster ;_;
But if I have to make an Array I have to inherit from Indexable which inherits from Collection which inherits from Object! How else am I supposed to implement an Array?
Admittedly this is why I like C#'s ‘implements’ paradigm. Doesn’t have to inherit, it just has to fulfill the contract, and then you can pass it to anything that expects the interface it implements. Keeps you from building giant trees.
As a rust developer I feel obligated by religion to make this comment:
Then you’d love rust! Rust only has “interfaces” (called traits) but doesn’t have inheritance. You just have traits that don’t inherit from anything and structs (that don’t inherit from other structs) that implement X amount of traits.
So you can have the good things about OOP without the bad ones.
And these traits allow you to make trait objects, which would be like regular objects in C# (with vtables for the methods). If 2 different structs implement the same trait, you can “downcast” them to a trait object and store them in the same array. Or pass it is an argument to a function that wants something that implements that trait but doesn’t care about the specific struct. You can of course cast it back later to the original struct.
I like interfaces as a supplement to inheritance. The strength of inheritance is getting all of the internal functionality of the parent class, while still allowing you to differentiate between children.
Interfaces are useful for disparate classes which don’t have much in common besides fitting within a specific use case, rather than classes that are very similar to each other but need specific distinguishing features.
I totally agree on this. I found that often things that appeared to need inheritance at first glance often didn’t if I gave deeper thought to it.
Granted I was working on much smaller projects rather than crazy huge multi team enterprise apps, but I’d guess that even then this is a good “rule of thumb”.
Cool, good to know someone else has the same experience.
Ive been on a couple of multi-year projects and they are NOT fun with OOP + developer went crazy with patterns they were experimenting at the time. Its what made the “rule” pop up to begin with.
Every class needs to use DI for calling other classes, even though we’ll have anyway just a single implementation for all of them, and we won’t be using this flexibility at all (not even for tests where it might be useful for mocking dependencies).
Methods calling other methods? Heresy! There needs to be two or three interceptors on there, and some indirection over RabbitMQ using spring-integration, at the very least.
Was gonna say just this. Inheritance is powerful but something to reach for sparingly. 80% of the time aggregation and composition can solve the problems.
I’ve cleaned up too many inheritance nightmares in my day from people who insisted inheritance was the way to go.
We use it a lot when we have a solution that works for 95% of customers and a few need random things.
Else we will have multiple markets changing the same function with a thousand if else
Main issue is that makes it so that some functions are never generalized, like when customer A wanted to use an equal filter, customer B wanted a IN filter, and the rest have no filtering capability at all.
I’ll say this now.
Inheritance is the most misused capability of OOP which programmers think makes their code look smart, but most of the time just makes a giant fucking mess.
I’ve moved away from Classes in general unless it truly makes code more streamlined. The main language I was taught in highschool was Java and it’s just so liberating not needing to turn everything into an object.
But recently I’ve used a Class specifically for Inheritance. I’m making an extension to Pytorch and almost everything in Pytorch uses Tensors as a medium. I made a new kind of tensor that inherits the Tensor class to add specific restrictions on how it behaves. Because of this, this new tensor object can be used with any of the preexisting pytorch functions while also validating the results, reverting to a Tensor if it becomes invalid.
Even in this situation though, all my programming logic rests in it’s own static functions, and the class contains functions that call the static version. The only actual logic the inherited object handles is validating the data.
Because of this, I feel like inheritance is most useful when you’re inheriting someone else’s code to make it compatible with their library. I don’t think I’ll ever inherit my own objects because that’s how you end up with Java.
Its the best/worst thing about OOP no matter what language.
We had a rule at work that if you are 3 levels or more down an inheritance tree, then you are too far. The cognitive load is just too much, plus everything stops making sense.
One level can be great (MVC all have great conventions, MCP as well). Two can be pushing it (Strategy pattern when you have physical devices and cant be connected all the time, Certain kinds of business logic that repeat hundreds of times, etc…) But even there you are kinda pushing it.
I need code that I can look at a month from now and know WTF is happening. And sometimes its better to have less DRY and more comprehension. Or maybe im just a forever mediocre dev and dont see the “light”. I dunno.
composition can help with all of that. factories, strategies, injections are all composition patterns that work fine.
business logic that repeats? extract it to it’s own thing (class, function, etc) and pass it as a param to the supposed childs.
mvc? controllers don’t need to extend anything, just have them accept the framework through the constructor and request and response as args. views? same. models? perhaps only if doing an active record, but a repo pattern with plain objects is a good pattern too.
I never seen a clean inheritance implementation for a decently sized problem. it mostly works for tiny ones.
When I first started using Go I bemoaned the lack of true inheritance and classes. Now I love it.
I thought it didn’t have classes in name only, isn’t a struct with methods basically a class?
Depends on what you mean by “basically a class”. If you mean inheritance, overriding, and more generally class/inheritance based polymorphism, no, it does not. Those require dynamic dispatch, which Go does not have (for concrete types, which is what we’re talking about here).
a class can be inherited from, a struct can not.
This is exactly how I feel too. A little bit of repetition is totally worth it, versus having inappropriate coupling, or code that jumps in and out of parent/child classes everywhere so you can hardly keep it in your head what’s going on.
I freely accept that I AM a mediocre dev, but if that lends me to prefer code that is comprehensible and maintainable then I think being mediocre is doing my team a favour, honestly.
@tiramichu
It’s this mentality that shows you aren’t mediocre. Simplicity requires more skill, not less.
@mesamunefire
Yup. They made it to the other side of the bell curve meme. Most developers have an OOP phase until they learn that it’s utter bullshit.
@jason
I do like being able to easily bundle properties and functions together. I think objects are useful if kept in their simplest form.
Though I think some would argue that not using inheritance and interfaces and such precludes it from really counting as OOP
I can definitely respect a limited approach. I personally don’t find any benefit from it. Anecdotally, I’ve become much more productive since switching from OOP style C++, to just straight C. I think a lot of that comes from the boilerplate and ceremony required to make it do the thing, but in C, you just do the thing.
I also think even using objects tends to encourage poorer design choices by thinking in terms of individual items (and their lifetimes) which is enforced by the constructor/destructor model. As opposed to thinking in terms of groups of items which leads to simpler and safer code.
Thats kind of you to say 😀
PTSD flashbacks to the codebase I started on in 2008 which had… I don’t even remember. Like six or seven levels. Fucking nightmare. I did a printout of the analysis Doxygen gave me and it ended up as a 4x3 meters poster ;_;
WTF
But if I have to make an Array I have to inherit from Indexable which inherits from Collection which inherits from Object! How else am I supposed to implement an Array?
Admittedly this is why I like C#'s ‘implements’ paradigm. Doesn’t have to inherit, it just has to fulfill the contract, and then you can pass it to anything that expects the interface it implements. Keeps you from building giant trees.
As a rust developer I feel obligated by religion to make this comment:
Then you’d love rust! Rust only has “interfaces” (called traits) but doesn’t have inheritance. You just have traits that don’t inherit from anything and structs (that don’t inherit from other structs) that implement X amount of traits.
So you can have the good things about OOP without the bad ones.
And these traits allow you to make trait objects, which would be like regular objects in C# (with vtables for the methods). If 2 different structs implement the same trait, you can “downcast” them to a trait object and store them in the same array. Or pass it is an argument to a function that wants something that implements that trait but doesn’t care about the specific struct. You can of course cast it back later to the original struct.
I like interfaces as a supplement to inheritance. The strength of inheritance is getting all of the internal functionality of the parent class, while still allowing you to differentiate between children.
Interfaces are useful for disparate classes which don’t have much in common besides fitting within a specific use case, rather than classes that are very similar to each other but need specific distinguishing features.
I remember some crazy stuff back when I had to work with a Java + ember.js project. Everything was like that.
@mesamunefire
@tiramichu
I totally agree on this. I found that often things that appeared to need inheritance at first glance often didn’t if I gave deeper thought to it.
Granted I was working on much smaller projects rather than crazy huge multi team enterprise apps, but I’d guess that even then this is a good “rule of thumb”.
Cool, good to know someone else has the same experience.
Ive been on a couple of multi-year projects and they are NOT fun with OOP + developer went crazy with patterns they were experimenting at the time. Its what made the “rule” pop up to begin with.
Hold on, I’m in the middle of drawing an inheritance graph so I know how Dog is related to AircraftCarrier.
public interface ICanTravelThroughTheAir { } public class Flea : ICanTravelThroughTheAir { } public class AircraftCarrier { private readonly List<ICanTravelThroughTheAir> _aircraft = new(); public void AddAircraft(ICanTravelThroughTheAir flyingThing) { _aircraft.Add(flyingThing); } } public class Dog : AircraftCarrier { public void Woof() { Console.WriteLine("Bitch I'm an aircraft carrier!"); } } public static class Program { public int Main(string[] args) { var dog = new Dog(); for (var i = 0; i < 10000; i++) { dog.AddAircraft(new Flea()); } dog.Woof(); } }Now someone needs to make it an entity component system!
Attempt 1:
You forgot the component part.
Needs more
AbstractDefaultProxyBeanFactoryFactoriesAnd dependency injection!
Every class needs to use DI for calling other classes, even though we’ll have anyway just a single implementation for all of them, and we won’t be using this flexibility at all (not even for tests where it might be useful for mocking dependencies).
Methods calling other methods? Heresy! There needs to be two or three interceptors on there, and some indirection over RabbitMQ using spring-integration, at the very least.
This is how you write proper enterprise-level software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
Not even unnecessarily templated, B- at best
Aggregation > composition > inheritance
Was gonna say just this. Inheritance is powerful but something to reach for sparingly. 80% of the time aggregation and composition can solve the problems.
I’ve cleaned up too many inheritance nightmares in my day from people who insisted inheritance was the way to go.
I learned about it in school and we didna few assignments for it
But… never seen or heard anyone mention it outside of that
I guess we can make up some nische vases
I did hear it can be useful for video games though. But then again im sure people can manage fint without, as well
It’s wildly useful, when you store a lot of similar stuff, or treat a lot of similar stuff etc.
Like a GUI, a rendering engine or a scientific soft. Video games, any soft with users, and so on.
I get that people misuse it but for me it’s wild that people think you should like program without it, like at all cost.
We use it a lot when we have a solution that works for 95% of customers and a few need random things.
Else we will have multiple markets changing the same function with a thousand if else
Main issue is that makes it so that some functions are never generalized, like when customer A wanted to use an equal filter, customer B wanted a IN filter, and the rest have no filtering capability at all.
And polymorphism is the only way you could expose those composite Interfaces as bindings on C API based languages. And polymorphism is part of OOP.
If we take the text book definition of OOP, then the kernel is OOP …