If Inheritance is so bad, why does everyone use it?

https://buttondown.email/hillelwayne/archive/if-inheritance-is-so-bad-why-does-everyone-use-it/

by harperlee • 2 years ago

198 376 2 years ago

signa11• 2 years ago

huh :o) the wisdom since late 90's has been to avoid it like a plague, at least in c++ circles. for example, see numerous articles in 'guru-of-the-week' by herb-sutter.

the same wisdom can be applied elsewhere as well, there is no need to keep discovering the same truths in different contexts again, and again.

stingraycharles• 2 years ago

Yeah in C++ especially nowadays using compile-time traits is much, much more idiomatic.

constantcrying4• 2 years ago

huh :o) the wisdom since late 90's has been to avoid it like a plague

I am sure that hundreds of thousands of students have at some point heard that these hierarchical organization of data is how you should model a system.

est• 2 years ago

IMHO inheritance works and only works for graphics related programming, e.g. GUI and games. Visual objects can be abstracted in the manner of inheritance.

mattnewport3• 2 years ago

Inheritance doesn't work well for games, that's why so many games take a component based approach like Unity, or full blown ECS.

lewispollard3• 2 years ago

Well, it does work well for the engine part of game engines, and graphics related code in particular as the GP says - it's just gameplay code where OO falls a bit flat.

professoretc• 2 years ago

The implementation of inheritance (more specifically, polymorphism and dynamic dispatch via vtables) is a problem in games, because it adds an extra layer of indirection, and screws with cache locality. But the semantics of inheritance (X ISA Y) still apply. In an ECS, the implementation is different (struct-of-arrays) but you can still think of an entity as "inheriting from" the various components its built from.

fxd123• 2 years ago

That's strange because I was about to comment the exact opposite. ECS is for games, inheritance is for almost everything else

ipaddr2• 2 years ago

For games having your character as a type of a general class fits well. Having enemies be a type of a class with a base of abilities can fit well too. Weapons, etc all module well. Game play. Scenes.

davedx• 2 years ago

This has more or less been my experience too. Things like UI toolkits or game engine primitives are often solved nicely with inheritance.

I've been doing a lot with LeafletJS lately, and it has some light inheritance around its drawing primitives (things like boxes, circles and lines you draw on top of maps). It works well.

For 3D engines you still need to be quite careful with where you apply it though. It's possible to get into a huge mess if you use it too much.

flohofwoe• 2 years ago

Especially in games, inheritance doesn't work all that great and had been replaced by composition via components a long time ago where each component implements one specific aspect or feature of a game object and can be (more or less) freely combined with other components.

KevinMS• 2 years ago

and it became popular at just about the same time as GUI programming, coincidence?

cess114• 2 years ago

The picolisp database convinced me that it also can work for databases, where it's used both for data storage, querying and as a GUI backend.

doomlaser• 2 years ago

Lots of design patterns have their uses, but can suffer when applied too overzealously.

JauntyHatAngle• 2 years ago

Like almost anything in IT, if you are good at using a hammer, you treat everything like a nail.

chii• 2 years ago

if you're good at using a hammer, the nail will be hammered in perfectly and without faults.

The only problem is if you're bad at using the hammer, and you only know how to use a hammer.

high_na_euv• 2 years ago

Do they? I rarely see people using it directly and I think this is fine

angiosperm2• 2 years ago

Most of us have no contact with Java. But Java offers little else than inheritance to use to organize a system, so Java coders use it for everything. They are not exactly wrong, except in using Java at all. But sometimes is all that is allowed.

pgwhalen• 2 years ago

This is much less true for modern Java than it used to be, with records, pattern matching, sealed classes, etc.

The trick though is you actually have to use modern Java, which means you need to both be on the right version of Java, and have developers that understand the value/power of these newer constructs. Which is surprisingly rare for a programmer that self-identifiers as a Java programmer.

bedobi2• 2 years ago

java offers composition, like pretty much all programming languages

if you have a person class and you have students and teachers

the correct thing to to is NOT to make student and teacher inherit from person

it's to make student and teacher have a person attribute + the other attributes that constitute a student and teacher respectively

brodo• 2 years ago

Same here. For me, implementation inheritance is a code smell. But I rarely see it.

KorematsuFredt2• 2 years ago

Here is my take on it.

At one point "Object Oriented" became "Blockchain" (or now Gen AI) of those times. You had to be "object oriented" in order to be taken seriously. This applied to everything. Even finished software products were called "built using object oriented".

The esoteric concept of inheritance became popular after that. At some point it became so popular that people figured out that it is not really a good thing.

blowski• 2 years ago

Pragmatists used inheritance because it gave a quick benefit now, and the longer-term costs were ignored. Some pragmatists became successful because they moved quickly, so the "Programmers from the Church of Purity" used inheritance because successful companies used inheritance. When inheritance was no longer the quickest way to move quickly, the pragmatists moved on. The Church of Purity now bangs on about Functional Programming in the same way for the same reasons.

mewpmewp23• 2 years ago

FP rather slows things down though.

throw_m239339• 2 years ago

Pragmatists used inheritance

Because at some point mainstream OO languages made inheritance easy and composition harder, nothing more.

Composition with Java used to be verbose. Inheritance declaration was simply a single keyword.

If Java had "mixins" from the start, people would have used composition way more.

pyrale4• 2 years ago

The Church of Purity now bangs on about Functional Programming in the same way for the same reasons.

FP in the industry is a niche thing, so the two phenomena are not really comparable.

KorematsuFredt2• 2 years ago

Pendulum swings once it is this way then another way.

blarg1• 2 years ago

Also a semi religion, I'm always seeing people say before OOP everything was terrible, and everything good thing is due to OOP (eg structs, methods, polymorphism)

bluetomcat2• 2 years ago

In the 1990s, it coincided with the proliferation of GUIs and their respective programming interfaces. Most frameworks use hierarchies like Object->View->Control->Button->ImageButton. Then people decided that this is the way for modeling abstract problems that don't have to deal with visual or real-world entities whatsoever.

dsego• 2 years ago

And you would get nice automatic completion when doing object name, dot, and waiting for the IDE to list all possible methods. This was exploratory programming, the copilot of its time.

fardo• 2 years ago

I think there’s a tension between the tinkerer, blogger and hobbyist side of the field, and anonymous 9–to-5 workhorse line of business programming in this discussion.

The core reason everyone uses it seems to me to be essentially the same reason the former groups hate it - it’s what everyone else does, it’s an incredibly square and “day-job”-esque approach to one’s tooling and architecture, it often reeks of bureaucracy, compartmentalization, and organizational superstructures often unrelated to the technical work, dictated primarily by managerial fiefdoms and needs to organizationally coordinate, and it’s a well-defined space with extremely predictable solutions and headaches, and therefore has very little excitement or novelty to offer.

Animats• 2 years ago

Many of the headaches associated with Rust come from an inability to reference from owned to owner. Affine types have much more impact on design than inheritance vs. composition.

bl4ckm0r32• 2 years ago

OOP is easy to understand and explain and it makes sense initially, plus a lot of people specialize in languages/frameworks that enforce it, so it becomes easy to get trapped in the OOP world. It also usually comes with DDD (which is a solution to a problem you shouldn't have had in the first place) which is a way to limit the damages of OOP into contextual areas. I also think the blanket statement (OOP is bad) does not apply necessarily everywhere. A good mix of composability and a bit of inheritance where it makes sense is the best way imo.

cess114• 2 years ago

I disagree. Starting with separating class and object have never been helpful when I've tried to teach computer programming, while functions seems to have been more intuitive to those people.

After a while you get to closures, which are pretty much objects without classes, and then factory functions that produce closures and there you have something like a class as well. If I were to design a course I'd probably follow this flow to get to 'OOP' in that sense.

xwolfi• 2 years ago

But you go from the bottom up here, I don't like to describe it that way.

I prefer to say that we naturally classify objects around us using fuzzy boundaries like "a house", "a cat", which don't exactly mean anything: they are templates we use later to actually generate an actual house, or an actual cat (on a piece of paper as a drawing for instance).

The world being separated between our internal classes and the interactive instances of them, we can code that way too: we look for what we actually need in a concept, name it and define only what we need, then instantiate several concrete actors interacting together. Each actor is complete, well defined, with contracts for interactions.

You can then start building on top of this more complex systems, talking in English and defining rationally the world of your little model.

If you start talking about functions, you're basically aliasing a memory address for a bunch of code: you'll goto that function address, with some parameters at some other address, do a bunch of things and put the result in another address for the next function to process. You're building at best a suite of pipelines, which ends up being a little bit too technical and static for my taste.

Another way to defend modelling a software with classes and object, in my view, without trying to talk about functions, is the blank page effect: imagine arriving at random at some assignment. You understand vaguely the business problem, now you need to code a solution. You have 6 months, will generate a few millions a year and will require a team of 10 people eventually to test, maintain, operate and debug: you start with defining functions generating functions with callback parameters in Python, or you launch IntelliJ and you do a Java class model ? I'd be terrified modelling complex problems with just functional pipelines, I think it's just way more obvious to talk about objects at all time if you're gonna do something that is not just processing inputs into well defined outputs.

zelphirkalt• 2 years ago

Some modern programming languages do not even have classes to inherit from. Instead they have concepts like traits and structs, which decouple structure and behavior.

julienreszka• 2 years ago

Nowadays I have rarely seen it if ever

cess114• 2 years ago

Smalltalk having a more or less revolutionary developer experience was likely quite important. A graphical interface to your system where you can traverse a tree and inspect _everything_, and more importantly, change it.

In Smalltalks as I know them, which is sporadically and shallowly, inheritance seems to be used as a factoring tool, when you break down functions into smaller functions there's a structure in which to place them with the implicit incentive to put them as high up as possible.

To me it seems to work pretty well, but it's also a rather weird environment where even classes themselves are objects.

In Java one can get around inheritance by using injection into an attribute in a wrapper class that extends or changes an object API. This leads to a similar decoupling as more functional composition, but you pay by having more objects swimming around in the VM during execution. Extending on the class level (i.e. in declarations of classes, interfaces, traits and the like) instead of the object level might have effects on performance and resource management.

Usually that likely doesn't matter, but it might. In Java-like languages I tend to use inheritance as a quick way to abstract over or extend functionality in a library class, I get the public methods 'for free' in my own class without having to write the wrappers myself. And that's usually where I stop, one level of inheritance, since Java isn't as inspectable and moldable as, say, Pharo, and doesn't give the same runtime ergonomics with large class/object trees.

moshegramovsky2• 2 years ago

I work on a very large codebase. We use inheritance and composition. I totally agree that inheritance should be used carefully. However, there are times when composition requires a lot more code and downstream maintenance.

Let's stay I have a base class A. Let's say I have 70 classes that inherit from A.

These classes must serialize/deserialize from disk.

My choice here is that I can add a new data member to A and then update the read/write method in one place, or I add a new data member to all the classes that are derived from A, meaning that I get to update 70 classes. Seriously? Who would think this is a good idea? You'll have to write 70 times as much code... there will be times when that's definitely a very bad idea.

Maybe don't use inheritance. Then give every class its own "Name" data member like std::string c_nName. Every class can have its own function to set the name, or we could use an unencapsulated free function and do things like C. Except then the experts will say things like "well, now you're doing C with classes". Then you get a ticket that the user can enter bad names. You can then figure out some way to validate the names, right? That could be a free function, or maybe write some class called NameValidator. Except now the experts say you're writing C++ like Java. Too many classes, too few classes, too many objects, too few objects, too may free functions, too few free functions.

C++ expert of the month may say X, Y, Z, but look at Microsoft's APIs.

Inheritance is everywhere.

Look at any open source C++ project.

Inheritance is everywhere.

Does that mean that you should make something like:

--B : public A

----C : public B

------D : public C

--------E : public D

----------F : public E

Or this:

    A  B
    \  /
     C

Not unless you have a damn good reason. But the point is that inheritance is a valid tool and it can reduce bugs, code duplication, maintenance.

Right tool for the job, yeah? I once read something in the C++ FAQ that said something like "Don't take advice from people who don't understand your business problems."

gridspy• 2 years ago

Let's stay I have a base class A. Let's say I have 70 classes that inherit from A.

The alternative case is that you have 70 classes that CONTAIN A. You still only have to change A.

moshegramovsky2• 2 years ago

Yes, but in my example, in the 70 classes, all the ::Read and ::Write methods must still say:

    a.Read( ... )
    a.Write( ... )

And depending on the use case and design, they also need methods such as:

   A& GetA() { return a; );
   const A& GetA() const { return a; }

planede• 2 years ago

The answer is that you retain A as a pure interface and maybe you add a convenience base below A that adds the data member, then you inherit from from the convenience base for your 70 leaf classes. You can also use CRTP for the convenience base, if it's appropriate. You can still avoid confusing interface and implementation inheritance.

drewcoo• 2 years ago

Not even wrong.

Inheritance isn't necessarily bad.

If anything is common, someone will try to seem like a brilliant iconoclast by writing an essay against it. The particular essay in this case was from a Pythonista (not surprising, given Python's weird love/hate with objects):

https://solovyov.net/blog/2020/inheritance/

And not everyone uses inheritance.

Maybe you have another question, like "why would someone use inheritance?"

peter-m80• 2 years ago

Speak for yourself, I don't use it.

bigstrat2003• 2 years ago

I don't think inheritance is bad at all. It is very often the easiest way by far to model a problem. Sure, it's not perfect, but I think it is wildly overhated by a vocal minority.

neonroku• 2 years ago

Depends on how you use it, but in Java I prefer to use interfaces and no subclassing. I find classes with abstract methods hard to reason about, and much prefer to leverage Functions/lambdas where possible.

arethuza• 2 years ago

Have you ever seen wildly over-architected OO code where everything seems to be an abstract class and it seems impossible to find out where stuff actually happens?

Inheritance is like a lot specialised tools - it can be useful in some situations but I think those are rarer than supporters might thing. Completely refusing to use inheritance and always using inheritance both seem like extreme views that should be avoided.

pyrale4• 2 years ago

You haven't lived life to the fullest until you've had to debug an issue in a 12-layer-of-inheritance class with the original call ping-ponging a couple dozen times across the layers and overrides everywhere.

I guess one could say this would be workable with proper tools, but the IDEs just aren't there. Move up a level in inheritance, ctrl-click on a call? It was overriden somewhere in the hierarchy, but the IDE will send you to the parent-class definition regardless.

touisteur4• 2 years ago

Feels like that time my physics PhD student girlfriend asked me "hey you're a programmer, right" and I was one until I discovered ROOT and suddenly I lost taste for life and anything related to Computers.

kaba05• 2 years ago

Sure, but I have also seen C code where random structs with function pointers are passed to god-knows-where, and I will take inheritance over that any time of the day.

bluefirebrand• 2 years ago

This is every OO code I've ever seen, honestly

TheBigSalad7• 2 years ago

I've seen that same problem sans a deep inheritance hierarchy.

MattPalmer1086• 2 years ago

I have found that single inheritence can be useful but it is very restrictive.

More than once, I have found an inheritance hierarchy that made sense when first created no longer models the problem well. It becomes hard to change it at that point.

Frequently I find I really want to mix in cross cutting concerns across different hierarchies. This isn't really a surprise; most problems do not naturally decompose to only a single view of things.

I don't mind abstract base classes containing common functionality, so it's useful there, but mix ins would be better to be honest.

thiht• 2 years ago

I think that’s just what you’re used to. Since I switched from Java to Go 7 years ago, I don’t think I’ve missed inheritance a single time. I haven’t needed to model anything with inheritance once. There are definitely things I’ve missed from Java, but not inheritance.

jerf• 2 years ago

A lot of people who only know inheritance and can't understand why a lot of us slag on it so much don't understand how inheritance conflates implementation and interface. Polymorphism based on interface is a fundamental tool of programming. The way inheritance also drags along an implementation turns out not to be, and to probably be more trouble than it's worth. There are other ways of bringing along implementation, including the basic function, and those work better.

When inheritance is your only tool for interface, I absolutely agree that it looks fundamental, but the fundamentalness is coming from the interface side. Once you separate out interface from implementation, it turns out I have little to no use for the implementation portion.

I have also been programming in Go for a long time now. I sketched out an inheritance system once for an exercise. It's doable, though it's a terrible pain in the ass to use. I've kept it in my back pocket in case it is ever the right solution to a problem even so... but it never has been. And that's not because of any irrational hate for the pattern itself. I've imported other foreign patterns sometimes; I've got a few sum types, even though Go isn't very good at it, because it was still the best solution, and I've got a couple of bits of code that are basically dynamically typed, again because it was the best solution, so I'm not against importing a foreign paradigm if it is the correct local solution. Inheritance just... isn't that useful. The other tools that are available are sufficient, and not just begrudgingly sufficient or "I'm insisting they're sufficient to win the argument even though I know they really aren't"... they really are sufficient. Functions are powerful things, as the functional programming community (it's right there in the name) well knows.

constantcrying4• 2 years ago

I have never really seen it work. To me it seems it can work if and only if you are doing serious waterfall projects, with a tightly bounded scope.

If you have to model your data exactly once I believe it can work. But if you are doing any kind of agile, or even somewhat flexible waterfall, you will find out that at some point none of your data models work.

BeetleB2• 2 years ago

I don't think inheritance is bad at all. It is very often the easiest way by far to model a problem.

I think the point of the article is that in some (very popular) languages, inheritance comes with a lot of baggage - precisely because classes in those languages support 3 different use cases. It's not saying that your usage is bad, but that your language didn't provide you with the best tool(s).

A lot of how people use classes can be solved via ADTs - which are much simpler to grok.

A lot of how people use classes can be solved via namespaces/modules, but not all languages have good support for them - so they use classes.

Etc.

pvdoom• 2 years ago

IDK, I recently did a big presentation on the topic in my company's Python community and there were tons of people that were genuinely surprised it's not great. And people in my department love throwing random classes that inherit from everything in the universe for no reason at all... for python. Like not even Java or C#. And coming in as the lone new-comer its not going to be easy to convince everyone that has been there for years that the common sense aint great.

jillesvangurp• 2 years ago

Kotlin has a few nice patterns here. It allows inheritance but only if you mark your class as open (it's closed by default). This prevents people inheriting from things that weren't designed from that. It also has extension functions, which allows you to add functions and properties to types without having to inherit from them. This is very nice for fixing things that come with Java libraries to be a bit more Kotlin friendly. Spring offers a lot of Kotlin extension functions for its Java internals out of the box. Another nice pattern is interface delegation where you can implement an interface and delegate to another object that implements that interface:

    class Foo(private val myMap: Map<String,String>=mapOf()): Map<String,String> by myMap

This creates a Foo class that is a Map that delegates to the myMap property under the hood. So you side step a lot of the issues with inheritance; like exposing the internal state of myMap. But you can still override and extend the behavior. Replacing inheritance with delegation is built into the language.

The net result of this is that inheritance is rarely needed/used in Kotlin. It's there if you really need it but usually there are better ways.

Scala and other languages of course have similar/more powerful constructs. But Kotlin is a nice upgrade over Java's everything is non final by default (or generally defaulting to the wrong thing in almost any situation). Go has a nice pattern based on duck typing where instead of declaring interfaces, you can just treat something that implements all the right functions as if it implements a type. Rust similarly has some nice mechanisms here. All these are post-Java languages that de-emphasize inheritance.

frizlab• 2 years ago

Same with Swift

pdpi• 2 years ago

One of the ways that I think Kotlin and Rust are objectively better than Java and C++ is in that they have saner defaults than their predecessors (like open/final and mut/const).

I've lost count of how many talks I've watched by Kate Gregory where she advocates for people tagging everything they can as const in their C++, but asking people to eat their veggies never works.

jonnycomputer3• 2 years ago

Sane defaults are the bomb. Defused bomb.

v1sea2• 2 years ago

The article has a nice history review of inheritance, but it would have been useful for there to be some concrete examples.

The worst example of inheritance I've ever found is in java Minecraft's mobs[0]. It is very deep in some places and has numerous examples of sub classes not fully implementing their parent interfaces.

Example 1: Donkey[1]

Donkey > Chested_Horse > Abstract Horse > Animal > Ageable Mob > Pathfinder Mob > Mob > Living Entity > Entity

Example 2: Blaze[2]

Blaze has a bit for 'Is on fire', but how is this any different from Mob 'Is aggressive'? Blaze > Monster > Pathfinder Mob > Mob > Living Entity > Entity

[0] https://wiki.vg/Entity_metadata#Entity

[1] https://wiki.vg/Entity_metadata#Donkey

[2] https://wiki.vg/Entity_metadata#Blaze

Sakos• 2 years ago

Both of those look like perfect cases for composition instead of inheritance.

coffeebeqn• 2 years ago

Anyone not using components for game objects is insane. How do you add a fire breathing horse without that

monknomo• 2 years ago

why is monster vs ageable mob a good cleavage? This is odd

TheBigSalad7• 2 years ago

Jesus, that's insane! The rule of inheritance is no more than 3 levels deep. 3!!

NotGMan• 2 years ago

Black and white extremist views.

Sometimes inheritance is extremely useful. Sometimes it's harmful. Sometimes it's not the best but the most practical nontheless.

Language concepts are tools. These people with extreme black and white views live under the delusion that there can be some "Perfect Language which will cause the program to never develove/get technical debt TM".

Pure delusion.

Real life is an approximation where you do what is best in practice, not in some delusional daydream of perfection which breaks the moment you try and bring it to reality.

nusl• 2 years ago

I quite like inheritance personally, assuming that it's done reasonably well and isn't a confusing mess.

captainmuon• 2 years ago

I feel people don't understand what inheritance and (object orientation in general) is useful for, misuse it, and then it gets a bad reputation. It's not about making nice hierarchies of Cars, Fruits, and Ovals.

For me the main point is (runtime) polymorphism. E.g. you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing. And if you want to avoid huge if-else statements, you should put the code for the special cases in the classes, not in each function that operates on them.

You can get this without implementation inheritance, it is also possible to just have something like interfaces. But I do find it very convenient to put common code in a base class.

bluetomcat2• 2 years ago

Polymorphism is doable in plain old C with lookup tables and function pointers. If that is the only benefit, what is the point of creating a language where everything is an object?

mrkeen7• 2 years ago

Polymorphism is doable in plain old C with lookup tables and function pointers

Not without casting. qsort is still:

    void qsort_r(void *base, size_t nmemb, size_t size,
                 int (*compar)(const void *, const void *, void *),
                 void *arg);

vidarh• 2 years ago

Because syntactic sugar and abstractions matter. You can do everything in assembly too, yet we prefer something higher level.

michaelrpeskin2• 2 years ago

what is the point of creating a language where everything is an object?

I think that's the ultimate culprit in everyone hating inheritance. If it weren't for Java, I think we'd all have a healthier view of OO in general.

I learned OO with C++ (pre C++-11), and now I work at a Java shop, but I'm luck that I get to write R&D code in whatever I need to, and I spend most of my time in Python.

In C++ and Python, you get to pick the best tool for the job. If I just need a simple function, I use it. If I need run-time polymorphism, I can use it. If I need duck-typing I can do it (in Python).

Without the need for strict rules (always/never do inheritance) I can pick what makes the best (fastest? most readable? most maintainable? most extensible? - It depends on context) code for the job.

Related to TFA, I rarely use inheritance because it doesn't make sense (unless you shoehorn it in like everyone in the threat is complaining about). But in the cases where it really does work (there really is a "is a" relation), then it does make life easier and it is the right thing.

Context matters, and human judgement and experience is often better than rules.

igouy3• 2 years ago

So we might guess that the language designers thought there were other benefits.

igouy3• 2 years ago

1981 "Design Principles Behind Smalltalk"

https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

UncleMeat• 2 years ago

Control flow is doable with gotos. What benefit therefore is structured programming?

Dynamic dispatch is implemented under the hood with lookup tables and function pointers. Sometimes, it is nice for a language to wrap a fiddly thing in a more abstract structure to make it easier to read, understand, and write.

ano-ther• 2 years ago

Yes. I have a framework for an embedded system that uses various types of sensors. When changing a sensor, instead of rewriting the polling loop for every new case, I can keep looping through ‘sensor[i]->sampleNow()’ and add the specifics in a class inheriting from SensorClass.

touisteur4• 2 years ago

Interface inheritance could do the trick then? Maybe function pointers even.

mrkeen7• 2 years ago

For me the main point is (runtime) polymorphism. E.g. you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing.

The runtime part is what I dislike. If I have a fruit which is an apple or a banana, I can't pass that to a method expecting an apple or banana. It can only be passed as a fruit.

And if you want to avoid huge if-else statements, you should put the code for the special cases in the classes, not in each function that operates on them.

This is common OO wisdom that I strongly disagree with. For example, in my program I have a few types (Application, Abstraction, Variable, etc.), and a lot of transformations to perform on those types (TypeCheck, AnfConvert, ClosureConvert, LambdaLift, etc.).

I prefer to have all the type-checking code inside the TypeCheck module, and all the closure-converting code inside the ClosureConvert module. I'd take the "huge if-else" statements inside TypeCheck rather than scatter typechecking across all my datatypes.

rtz121• 2 years ago

If I have a fruit which is an apple or a banana, I can't pass that to a method expecting an apple or banana. It can only be passed as a fruit.

You can by overriding the method on apple or banana. If your method is on some other object, then yes, you cannot do this unless your programming language supports multiple dispatch.

zbentley• 2 years ago

I prefer to have all the type-checking code inside the TypeCheck module

There are ways to have your cake and eat it too, here, at least in some languages and patterns.

For example, in Go you could define "CheckType" as part of the interface contract, but group all implementors' versions of that method in the same file, calling out to nearby private helper functions for common logic.

Ruby's open classes and Rust's multiple "impl" blocks can also achieve similar behavior.

And yeah, sure, some folks will respond with "but go isn't OO", but that's silly. Modelling polymorphic behavior across different data-bearing objects which can be addressed as implementations of the same abstract type quacks, very loudly, like a duck in this case.

kaba05• 2 years ago

The runtime part is what I dislike. If I have a fruit which is an apple or a banana, I can't pass that to a method expecting an apple or banana. It can only be passed as a fruit.

Heh? An apple is a fruit, you can pass it to any place expecting the former. Like, this is Liskov’s substitution’s one half.

With generics, you can be even more specific (co/in/contra-variance).

parpfish• 2 years ago

if i were writing an intro to programming book, i would introduce OO as a means of building encapsulation. i'd only get into inheritance in later chapters.

gentleman113• 2 years ago

You can have encapsulation without oop. Polymorphism is the real benefit of oop imho

eddd-ddde3• 2 years ago

Except inheritance is the premature optimisation of interfaces.

Inheritance forces you to define the world in terms of strict tree hierarchies, which is very easy to get wrong. You may even do a great job today, but tomorrow such properties don't hold anymore.

Regular composition allows the same functionality without making such strong assumptions on the data you are modelling.

sameoldtune3• 2 years ago

Arborescent vs rhizomatic approaches, to get philosophical.

dragonwriter4• 2 years ago

Inheritance forces you to define the world in terms of strict tree hierarchies,

No, it doesn’t.

Inheritance is the outcome of deciding to model some part of the problem space with a tree hierarchy (that potentially intersects other such heirarchies). It doesn’t force you to do anything.

I suppose if there was a methodology which forced you, as the only modeling method, to exclusively use single inheritance, that would force you to do what you describe, but…that’s not inheritance, that’s a bunch of weird things layered on top of it.

EVa5I7bHFq9mnYK2• 2 years ago

True. Modelling the world as a tree oversimplifies it, as there are also lateral and even backwards dependencies, and at a sufficiently complex level abstractions start to leak all over, making it a mess. But at some low to medium level of complexity it might work.

sameoldtune3• 2 years ago

You’re describing the strategy pattern, which is probably one of the most practical coding design patterns. Ex: each chess AI difficulty gets its own class, which all extend a common interface.

krapht• 2 years ago

I still find it funny that somehow the idea of runtime function dispatch via function pointer is called the "strategy" pattern.

VirusNewbie3• 2 years ago

For me the main point is (runtime) polymorphism.

But you don't actually care about runtime polymorphism here. You care about polymorphic behavior, which can be implemented in a much more composable way with parametric polymorphism.

layer87• 2 years ago

You can’t build a dynamic list of objects implementing the same interface in different ways with parametric polymorphism.

As another example, the Unix file interface (open(), read(), write(), flush(), close()) etc. is an example of runtime polymorphism, where the file descriptors identify objects with different implementations (depending on whether it’s a regular file, a directory, a pipe, a symbolic link, a device, and so on).

All operating systems and many libraries tend to follow this pattern: You can create objects to which you receive a handle, and then you perform various operations on the objects by passing the respective handle to the respective operation, and under the hood different objects will map to different implementations of the operation.

dblohm7• 2 years ago

Unfortunately a lot of developers are conditioned so heavily to believe that inheritance is intrinsically bad, that they contort their code into an unreadable mess just to re-implement something that could have been trivial to do with inheritance.

I'm not saying that I like it everywhere; IMHO it's a tool to be used sparingly and not with deep hierarchies. But it's not reasonable to avoid it 100% of the time because we're soiling ourselves over the thought of possibly encountering the diamond problem.

tombert• 2 years ago

I feel like Clojure-style multimethods accomplish this better than inheritance. I can simply write a dispatcher that dispatches the correct function based on some kind of input.

This is evaluated at runtime, thus giving me the runtime polymorphism, but doesn't make me muck with any kind of taxonomy trees. I can also add my own methods that work with the dispatcher, without having to modify the original code. I don't feel like it's any less convenient than inheritance, and it can be a lot more flexible. That said, I suspect it performs worse, so pick your poison.

BeetleB2• 2 years ago

I feel people don't understand ...
For me ...

Sorry, but right off the bat this is just painting you as an example of "There are N camps, and each camp declares the other camp as wrong."

Yes, that's what inheritance is for you. For others it is something else. Why is your way the one that "correctly understands" it?

The article itself covers this - that some languages have lumped 3 different concepts into one that they call inheritance, leading to the different camps and comments like yours. Your camp is specifically mentioned:

Abstract data type inheritance is about substitution: this thing behaves in all the ways that thing does and has this behaviour (this is the Liskov substitution principle)

CharlieDigital2• 2 years ago

    I feel people don't understand what inheritance and (object orientation in general) is useful for, misuse it, and then it gets a bad reputation. It's not about making nice hierarchies of Cars, Fruits, and Ovals.

Agree 100%. It starts from the earliest programming course where we just teach it all wrong; way to abstract (no pun intended).

One point to add to yours: well executed OOP allows for "structural" flow of control where the object hierarchy, inheritance, events, and overrides allow for the "structure" of the hierarchy to control the flow of logic.

I wrote two articles on this with concrete examples and use cases:

https://medium.com/codex/structural-control-flow-with-object...

https://medium.com/@chrlschn/weve-been-teaching-object-orien...

hahn-kev• 2 years ago

Read the first article, great example, I'll have to remember that next time I'm trying to teach OOP

tubthumper84• 2 years ago

Interesting articles!

I think the first part of the first article immediately introduces an anti-pattern - forcing the user to make an instance of a class just to be able to call a pure function. It's just unnecessary noise, either make them static methods, group them in an object literal, or import the module as a namespace.

Adding the "pattern" as a mutable public field is a bit sketchy, and would make it show up in intellisense, but hopefully nobody will access/modify it. Making the pattern as a `const` at module scope solves that problem but you handwave away that approach saying it "pollute the symbol space for intellisense", which isn't true (non-exported items aren't available outside the module).

The next section on validation is a good example of another anti-pattern. The example of:

    public get isUserValid(): boolean

is not a good way of doing it, because it relies on hopes and prayers that the user of the class remembers to call this. A better signature would be:

    function isUser(input: unknown): input is User

Notice the key difference - you can't get an instance of User without it being valid. There shouldn't be a notion of "yeah I have a User, but I don't know if it's a valid User". Your way allows people to operate with User, blissfully unaware of whether it is valid or not, hoping that they might notice the right method to call. Instead: Parse, Don't Validate [1]

Note that to do this correctly, you have to either:

1. Separate data and functions 2. If you must use a class, then hide the constructor and provide a static constructor with a return type that indicates the function can fail

[1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

_________

Part 2 was an interesting exercise in how the popular OOP patterns from the GoF book vastly overcomplicated code, negatively impact readability, and make following the code feel like Mario (the princess is in another castle)

No need for inheritance, abstract base classes, of any of that complexity, all of that could be done with:

    type ShippingCalculator = () => number
    
    const shippingCalculators = {
      USPS: calculateUSPS, 
      UPS: calculateUPS,
      FedEx: calculateFedEx,
      DHL: calculateDHL,
    } as const satisfies Record<ShippingMethod, ShippingCalculator>

Intellisense works fine of course, and code navigation (via F12) is straightforward and easy to navigate.

ElevenLathe• 2 years ago

I used to be an OO hater until I started playing with Smalltalk. In particular, I worked through the Pharo MOOC (https://mooc.pharo.org/), which teaches you exactly this: designing the hierarchy IS designing the control flow of the program.

That said, Smalltalky hierarchies are a nightmare in most other languages because another key part of the Smalltalk env is the tooling -- staying inside a running system and being able to edit code from within the debugger is absolutely great and keeps you in a flow state much better than any other workflow I've been exposed to (including Lisp + Paredit + SLIME). The result is that editing class hierarchies in blub-y OO languages is usually a massive pain in the ass, while doing it in Pharo or a similar Smalltalk env is fun and painless. This is why you can't practically write Smalltalkly in Python/C#/Java/etc. even if on paper they have all or almost all of the same features.

quaunaut5• 2 years ago

If people get it wrong so regularly, what value is it providing as a concept? These concepts are supposed to help us reach something better, if you have to add 30 caveats to every part of it, all it did was hide its own complexity from you, instead of managing it for you.

skydhash4• 2 years ago

Because the tree is a nice abstraction for some problems. But sometimes you need a collection of pure functions. Sometimes it’s best to think of your object as data blobs going through a line of map,filter,reduce functions. Not every part of your application is the same, use the right abstraction for the job.

bamboozled• 2 years ago

This is why "interfaces" is a better word and and a better concept to describe this paradigm, not inheritance.

Sankozi• 2 years ago

You can have polymorphism without inheritance and inheritance without polymorphism. The big problem with inheritance is that it is really tricky to write those base classes. Making class inheritable by default in programming language is often considered a big mistake, because only carefully designed and documented class can be safely extended.

commandlinefan• 2 years ago

I see that a lot - the alternative to inheritance, when inheritance does make sense, is code duplication, which is much worse than inheritance, or first-order functions, which many languages don't actually support or don't support efficiently.

Capricorn24817• 2 years ago

you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing

What does this have to do with inheritance? This is just a generic function.

And if you want to avoid huge if-else statements, you should put the code for the special cases in the classes, not in each function that operates on them

This doesn't sound any different from how people usually talk about inheritance.

I am not convinced it gives you anything more than composition does. Composition is very easy to setup and easy to change. And there are certainly functional ways to do runtime polymorphism.

SpaghettiCthulu2• 2 years ago

> you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing > What does this have to do with inheritance? This is just a generic function.

It's a generic function with compile-time compatibility checks.

datascienced• 2 years ago

Inheritance is not so bad for native UI stuff where it makes sense for the class libraries.

But in work code I don’t see it much. If it is used it is light weight. Often used incorrectly for splitting code into different files rather than actual inheritance (giveaway is one one derived class!)

nertirs• 2 years ago

I only tend to see inheritance in engines and libraries, where it makes sense to create more generic, reusable and composable code, since most of the functionality in these is defined by technical people.

It makes no sense to use inheritance in the business layer, because a single feature request can make a lot of the carefully crafted abstractions obsolete.

photonthug• 2 years ago

I've never seen it put quite like this, but it feels right and is refreshingly concrete. Trust the abstractions you can actually design/control for, treat all the other ones as suspect. One still needs the wisdom to tell the difference, but at least focusing on "feature request" focuses the mind. This is at least simple even if it is not "easy".

An argument against OOP where you first need to define/explain differences between composition/inheritance, Liskov Sub, compare and contrast with traits, etc is not really that effective when trying to mentor junior folks. If they understood or were interested in such things then they probably wouldn't need such guidance.

weinzierl• 2 years ago

My impression is the opposite, especially from when I used to work as a full-time Java dev. I often asked myself:

Is there a place outside of GUI programming where inheritance is used in non-habitual and useful way? I can't think of many.

More often than not you have a final class that you are supposed to use and the petrified hierarchy above that is of not much use.

dan-robertson• 2 years ago

Perhaps having some abstract class with a real and mock implementation inheriting from it, which can then be injected into your code for testing other components is one example.

Gibbon1• 2 years ago

I actually think with generics without type erasure and duck typing a language doesn't need inheritance. And when applications are built around passing data between services OOP tends to be less useful. (eggs are passed to the frying pan service and bread goes to the toaster service)

otikik• 2 years ago

Inheritance is a local maxima. When the hierarchy of classes to consider is small, it often “seems to fit”. It allows the programmer to progress quickly and with low effort as a lot of the code sharing behavior is provided by the inheritance mechanism.

Trouble often comes down the line. We keep adding classes, and soon we find that the hierarchy no longer is “shaped like a tree”. A soccer ball is a spherical object but also a sports equipment and a bouncing object, and there’s no way to organize those into branches.

Our reality isn’t “tree-like”, except when we simplify it extensively.

wwweston• 2 years ago

Hence traits.

gentleman113• 2 years ago

That’s true of all knowledge organizational structures though. Even with composition, you end up with hierarchies that later you might turn on their heads, and also, those structures might end up being cyclical.

Paradigm shifts happen and shake up even loosely organized into structures like human perception, and most people’s perceptions aren’t trees

cryptos• 2 years ago

My impression is that inheritance is in many common programming languages the easiest way to share code. Sharing code in another way would require some more thoughts and sometimes code, so the lazy programmer takes inheritance.

Traits as a general concept would be very useful in many programming languages, but only some (like Scala) have proper support for it. In principle a Java interface with default methods (implemented methods) is also something like a trait, but very limited compared to traits in Scala. I have no statistics, but my impression is that inheritance is much less used in Scala, because the language has an easy to use alternative.

Another example is Go, where structs with their associated methods can be embedded, what is exactly composition supported by the language. Since Go doesn't support inheritance, programmers obviously needs to use this approach, so you would never see inheritance in Go programs.

So, my conclusion is that the usage of inheritance depends on what the language supports and how easy it is to use.

ehnto2• 2 years ago

Traits and contracts or interfaces, but even still inheritance has it's merits. Being fast and easy is a benefit, and I find defensive programming in extensible systems can benefit from a foundation of expecting inheritance.

josephg5• 2 years ago

What do you mean by this sort of defensiveness? Can you give an example?

Supermancho3• 2 years ago

Traits are increasingly common.

https://en.wikipedia.org/wiki/Trait_(computer_programming)

whyever• 2 years ago

Rust also has traits, and no struct inheritance. I think it works quite well.

AndrewDucker• 2 years ago

It can be useful in the situation where you want to override functionality in a class without making the functions public.

If you're composing a class out of multiple chunks of functionality then all of the bits you want to call need to be public. If you're sublcassing and overriding then the bits you're overriding can be internal, and not part of your public API.

hkkwritesgmail• 2 years ago

I find that it helps most if we make algorithms the centerpiece of the design and then use inheritance to facilitate coding and make everything succinct. The days of unwieldy inheritance structures coming out of big design patterns are clearly over.

vegetablepotpie• 2 years ago

There’s a rule-of-thumb I’ve found about OOP where you want to use composition when extending data, and you want to use inheritance when extending behaviors.

The zoo animal metaphor that you often see used in teaching inheritance (lions are animals, simba is a lion all animals have a length, but lions also have claws etc.) is a bad perspective and you should never use inheritance to model a problem like that in the real world.

The only time I’ve used inheritance, has been on toy problems that didn’t need it. Not to say it doesn’t have its place but when I encounter it, it’s time consuming to peel back all the layers or deal with idioms that don’t quite fit a problem that a developer has enforced through inheritance.

gwbas1c• 2 years ago

The only time I’ve used inheritance, has been on toy problems that didn’t need it

See https://news.ycombinator.com/item?id=39999644

It's very useful when a base class provides an incomplete implementation, and the child class completes the implementation.

Sometimes I use it when testing, where the child class alters some behavior in a way that mocking can't do correctly.

In C# / Java, inheritance is used for setting up filters for exceptions

jonathanstrange3• 2 years ago

I prefer languages with full OOP, ideally with multiple dynamic dispatch. What I'm not fond of are languages like Java that overuse OOP design patterns, force you into them, or require lots of OOP boilerplate. If you have a class whose sole instance serves as a factory for other objects, you know you're on the wrong path. But I've never seen any coherent and sound arguments against OOP in general. Nobody forces you to use it, and, for example, it would be much easier to develop and deal with GUI frameworks in Go if it had classes with inheritance. As a rule of thumb, if for some reason your language drives you to emulate dynamic dispatch with explicit type switches on one or even multiple arguments, then it probably should have inheritance and dynamic method dispatch.

mrkeen7• 2 years ago

But I've never seen any coherent and sound arguments against OOP in general.

How about arguments for OOP? Especially for things which can't be done better elsewhere.

jonathanstrange3• 2 years ago

As others have said, GUIs are the place where OOP shines. There are no things OOP does that can't be done elsewhere, what happens in practice is that programmers invent their own ad hoc object systems and start programming in an object-passing style (see e.g. Gtk).

poisonborz• 2 years ago

My take is that after something becomes sufficiently popular and mainstream, for a lot of people who want to be seen as innovative, the only way is to lash out against it. See all the articles on how hellishly bad agile, php or javascript is. A lot of criticism is valid of course, but that is irrelevant in the larger scheme of things - there is a reason they became what they are today.

EVa5I7bHFq9mnYK2• 2 years ago

There is a lot of things in the world today that are very bad and very popular, not the reason to stop hating them.

EPWN3D2• 2 years ago

It seems like protocols solve 90% of the problems that inheritance does, but with 10% of the headaches. Instead of trying to ensure that two types can both be passed to a function that only knows about the parent type, just have a parameter that says "Whatever's passed has to conform to this, I don't care what it is otherwise."

vram223• 2 years ago

Code example?

layer87• 2 years ago

“Protocols” is Apple-specific (or Objective-C/Swift-specific) terminology. They correspond to types 1 and 2 of inheritance that TFA mentions.

david2ndaccount• 2 years ago

Python also has protocols: https://typing.readthedocs.io/en/latest/spec/protocol.html#p...

eyelidlessness2• 2 years ago

Protocols as a term have other prior art. Which shouldn’t be surprising because a protocol is also descriptive of interface boundaries between software products (such as, but not limited to, network protocols).

shagmin• 2 years ago

I'm guessing the closest equivalent in languages like Java or C# are interfaces, right? Underutilized IMO.

neonsunset• 2 years ago

Interfaces in C# are used way more often than abstract classes and inheritance. It is also becoming more important as there is more code written in Rust style with structs implementing interfaces for zero-cost dispatch through generic constraints e.g.

    void Handle<T>(T value) where T : IFeature1, IFeature2...

wdroz• 2 years ago

In C++, you can use C++20 concepts[0].

[0] -- https://en.cppreference.com/w/cpp/language/constraints

_flux2• 2 years ago

Nice in principle, but doesn't it make it quite difficult to analyze such code? E.g. finding places that use a particular function of a protocol.

I recall Pyright for Python is not able to find such call sites. But perhaps there are better implementations of the concept?

EPWN3D2• 2 years ago

A lot of OOP syntax has that exact problem because you don't use a fully-qualified method name. That's actually an upside of a janky C pseudo-OOP patterns. You have to call a function, that function has one name, one way of being called. So you can usually find all the call sites with grep (modulo macro explanations or something).

I could imagine a syntax that made you specify the protocol at the call site, e.g. for an object Foo that conforms to protocol Bar with method baz, you'd have to write obj->Bar->baz() as opposed to just obj->baz(). Or alternatively, Foo->Bar->baz(obj) if you want to make any given call site discoverable.

seanwilson8• 2 years ago

Nobody calls it this, but cascading styles in CSS is just like inheritance and I think should be avoided for all the same reasons. I feel it's a big part of why CSS at scale becomes unmaintainable. There isn't even a built-in way to compose two classes together if you want to avoid cascading/inheritance.

It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason.

ethanbond• 2 years ago

Obligatory: Tailwind

seanwilson8• 2 years ago

I tried to avoid mentioning that, but Tailwind is showcasing how to write CSS using composition from inheritance. But it can't overcome the knee-jerk reaction from many CSS developers that don't see the problems that comes with CSS cascade/inheritance. I think this is mostly because leaning on cascading rules is seen as a best practice and most aren't going to question best practices much.

gentleman113• 2 years ago

Explain?

danShumway6• 2 years ago

I'm inclined to semi-agree with this, although I'm not sure I'd be quite as adamant about it myself. But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor. The language is definitely oriented towards inheritance/cascade, but I think there are ways to avoid it.

There's some movement towards ::part as a proposal to grant some mixin behaviors (https://developer.mozilla.org/en-US/docs/Web/CSS/::part) but I've never messed with it, and it's applicable only to shadow DOM. But mixins haven't been a huge issue for me in even enterprise-scale styling that I've done.

Opinion me, everyone has their own opinions on this, use whatever CSS style works for you. This is not me saying that BEM is the best for everyone, just giving a perspective that as someone who tends to stick to vanilla CSS and who generally kind of hates working with technologies like Tailwind or CSS-in-JS, BEM-style vanilla CSS made CSS pretty pleasant for me to work with; I have a lot more appreciation for the language now than I used to.

So if you're annoyed by CSS but also get annoyed by pre-processors or think that Tailwind is just inline CSS under a different name[0], you still don't need to be bound to the cascade -- potentially look into BEM. No technology or compilation or dependencies, it's literally just a naming convention and style guide.

----

[0]: yes, I have used it extensively, please don't comment that if I used it more something would magically click, I already understand the points in its favor that you're going to comment and I've already heard the style/framework suggestions you're going to offer. It's fine if you like Tailwind, it's great if it helps you write CSS, you don't need to convince me.

seanwilson8• 2 years ago

But I do generally think that CSS is taught in a way that encourages some bad practice around cascade/inheritance. I will point out though that (at least in my experience), BEM solved the majority of these problems for me even without a preprocessor.

I think cascading is just a bad default, and I think methodologies like BEM agrees with this by teaching you ways to write CSS in ways that stops cascading from getting in the way.

Cascading styles are fine for styling how basic document content is shown (e.g. h2, p, a, li etc. tags) but outside of this, you generally don't want the styles of parent elements leaking into the styles of child elements. Cascading/inheritance styles is a useful tool to have, but not as the default.

I'm not saying Tailwind is perfect, but it's closer to "prefer composition over inheritance", where you can sprinkle in some cascading/inheritance where it makes sense.

Scarbutt2• 2 years ago

Do you have a CSS component framework that you can recommend for use with BEM?

vram223• 2 years ago

It looks like composition over inheritance has caught on as the better default in other languages

"Prefer composition over inheritance" was mentioned in an early page of the GoF book (the Design Patterns book) - in 1994.

https://en.m.wikipedia.org/wiki/Design_Patterns

no_wizard4• 2 years ago

It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason

I find this falls into generally two camps, those who want to fight the browser and those who don’t.

Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits.

The second camp tends to not fight the browser and embrace the browsers methodology. They embrace the cascade because it’s easier than fighting it, but it requires a more sophisticated approach and seeing styles in a wholistic manner, not isolated purely into components (though may be organized in a way that co-located them with relevant components)

Both work, ultimately, and modern tooling and approaches allow both to exist, but I will say, the second group often has a better grasp on keeping project maintainability over time in my experience.

coldtea2• 2 years ago

Those that tend to hate the cascade tend to fight the browser a lot, whether they realize it or not. Generally speaking, they want things to work a certain way (IE everything in isolation) and prefer to think of styles isolated bits.

So, wouldn't that be the browser fighting them, then?

They want something specific, and the broswer forces a paradigm upon them that they don't want.

They are the humans and the browser (well, the styling language of the browser) is the tool that should accomondate them, not the other way around.

cogman103• 2 years ago

the second group often has a better grasp on keeping project maintainability over time in my experience.

That's probably in the eye of the beholder and a necessity. If you are all in on the cascades then you have to limit the depth of your page structure, otherwise it becomes impossible to predict how things will ultimately render or what the impact of a change at layer 3 will have on the rest of the page.

Technically speaking, isolation is perfectly possible with webcomponents.

quaunaut5• 2 years ago

I'd ask what you mean by "fighting the browser"- as generally, the number one way to ruin the performance of your CSS is to introduce depth to it. In general, keeping everything isolated regularly leads to better rendering performance.

Buttons840• 2 years ago

Two camps I see are (1) those who want to hold the program in their head and be able to answer ever more obscure questions about the program using their understanding. And (2) those who try things until it works and then address problems as needed.

Do these two camps align with your two camps? Those who want control fight the cascade, others just fiddle with it until it looks good?

I don't mean to disparage either camp, because we need both approaches in the real world.

layer87• 2 years ago

It’s not only inheritance, it’s also lack of encapsulation and of separation of concerns, which leads to attack vectors like: https://news.ycombinator.com/item?id=39928558

ramijames• 2 years ago

I really agree with this.

There was a company that I worked at 10ish years ago with a SaaS built around Drupal. They had one monolithic css file that was 25000 lines. It was a nightmare. When I took over the front-end rebuild, went through it line by tedious line and broke it out into discrete components.

I think about that from time to time when building logic or other functionality. I'd much rather have a self-contained bit of code than a big thing that is so intertwined I'm terrified to touch anything.

cjpearson2• 2 years ago

CSS does actually call it inheritance[0], but it's commonly mixed up with the cascade. Inheritance applies to certain properties, so that when they are not specified on an element, an element inherits the value of the parent.

The cascade[1] determines how rules from multiple sources are merged.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade

pwdisswordfishc2• 2 years ago

CSS calls something completely different "inheritance". There is no class inheritance in CSS, because CSS classes are not OOP classes.

spankalee2• 2 years ago

The cascade is not much like inheritance at all. If anything it's more like composition because the styles can come from multiple sources, eg user styles vs author styles, multiple layers.

The cascade is so much not like inheritance that I wonder if you meant either the concept of selectors in general, or inherited properties?

seanwilson8• 2 years ago

Yeah, the other poster pointed out https://developer.mozilla.org/en-US/docs/Web/CSS/Inheritance and https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade.

I meant the concept that when you e.g. apply the style "color: blue;" to an element, all child elements get the same style unless you override it. I'm not saying it's identical to inheritance, but it's similar in that changes and additions at the top-level ripple down to lower levels, which I find causes most of the problems when writing maintainable code.

pointlessone• 2 years ago

It's because people don't understand cascade we end up with pages that have text in 18 different font sizes. Cascade was a brilliantly simple idea and gave great consistency of design easily. At the time it was great. I believe the only reason most people are mad at CSS is because specificity is hard to grasp and order-dependent resolution and you don't control it when you bundle 500 packages. You get scores of megabytes of CSS that can randomly change order. Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.

fcpk• 2 years ago

And not to forget that this also comes from a discrepancy between the fact a lot of people start with a design and want a CSS that matches that design, when CSS was made more as a theme system where you make a theme and let it handle placement and design. The result is clunky complex CSS to fight the browser into placing things an exact way and giving each element a different look.

In my opinion, this was a failure of communication from the beginning, with a huge divide between "I want my website to look like this because I drew it on paper with my designer friend" and "css is a cool new way of doing decent programmatic ux/ui.

seanwilson8• 2 years ago

It's because people don't understand cascade we end up with pages that have text in 18 different font sizes.

Variables and/or utility classes mostly solve this so not sure how it's related.

Since then we've got more tools to control cascade: layers, scopes, inherit/initial/revert/revert-layer/unset for every property, etc. But people still insist on inline styling. I get it, it's much simpler. But they will keep being unhappy until they learn cascade and stop fighting tools. Yes, learning takes effort but so does resistance.

Similar to inheritance-like features in other languages, I have learned it and find composition is the better default. It's too complex for too little benefit so I avoid it wherever possible.

I find maintainable CSS approaches are all about reducing the blast radius of style inheritance. So people are writing maintainable in sprite of cascading, not because cascading helps.

specificity is hard to grasp and order-dependent resolution

Specificity is another foot-gun to avoid for me. It's learnable, yet easy to forget later. When you're tempted to rely on specificity there's usually a more readable way to do it that's not going to bite you later.

Do you doubt the developers behind Tailwind library understand specificity and the cascade? They clearly must understand it, use it where it helps, and avoid it where it doesn't.

butlike3• 2 years ago

The cascade was born from a time when the hope was to apply your own styles independently of the site's style, without overriding theirs completely. I think the standard languished and fell out of favor, but that was the hope.

I'm having trouble finding the original video, but Jacob Thorton (@fat) did an insightful talk on the whole affair called "Cascading Shit Show"

pwdisswordfishc2• 2 years ago

Nobody calls it this, because it is not. CSS classes have nothing to do with OOP other than the word "class".

dboreham• 2 years ago

It's not bad. People like to feel smug by saying OO is bad and hence inheritance, meanwhile using some construct in their FP that is really the same thing.

chowells• 2 years ago

Can you explain how any construct in FP conflates subtyping and code sharing the way OO inheritance does?

tossandthrow• 2 years ago

you seem to be misunderstanding different terms. You can do OO without inhertitence.

inheritance is the worst as you grip with you types.

just use strategy patterns instead.

FrustratedMonky2• 2 years ago

Oh, darling, strap in because the Hacker News catwalk is serving us a spicy mix of opinions on inheritance in programming!

First up, we've got the crowd who treats CSS like it’s the ugly stepchild of inheritance, preaching the gospel of "composition over inheritance" as if it's the latest fashion trend.

Then there's the old guard, clutching their pearls and insisting that inheritance isn't the problem—it's just misunderstood, like a moody teenager.

Cue the functional programming aficionados, sashaying in with their "functions over classes" mantra, ready to throw shade at OOP's entire existence.

And let’s not forget the star of the show, the claim that inheritance is the VIP at the GUI and game development party, although some party poopers argue that the cool kids moved on to ECS systems ages ago.

Meanwhile, the language innovators are flaunting their Kotlin and Swift ensembles, dripping in modern features that promise to make inheritance feel so last season.

In the midst of this fashion war, there's a heated debate on whether we should be dressing our newbie programmers in OOP gowns or functional frocks from day one. And, honey, let’s not even get started on the industry’s trend chasers, who once hailed OOP as the next big thing, only to ghost it faster than you can say "blockchain."

In the end, it’s clear that in the world of programming, inheritance is either a timeless classic or a faux pas waiting to happen, depending on who you ask.

keiferkif• 2 years ago

It's funny how easy it is to spot a ChatGPT reply

FrustratedMonky2• 2 years ago

Do you think it is because it is too verbose? Long winded? A human wouldn't bother to write that much?

constantcrying4• 2 years ago

I think it is pretty clear that the reason inheritance is so prevalent is because it is a superficially good sounding idea, which again and again is being put in front of people.

I am sure that many, many people have had the experience of a professor tell them a nice sounding story about purely hierarchical data and went on thinking that this is the way data should be modeled.

Thankfully I believe that nowadays many people have understood what works and what doesn't work in OOP and we can actually try to get away from that model of data.

bartvk• 2 years ago

I don't know about other colleges, but when I teach my students inheritance, I tell them right away that it's a pretty bad idea. And that they will learn better ways in the next semester.

constantcrying4• 2 years ago

I can't speak for what has happened since I left university, but when I was a student there you got to here about cars, who are also vehicles, dogs, who are also animals and similar stuff. Which has "limited" applicability of how inheritance works in real software systems.

CyberDildonics• 2 years ago

This is exactly what I've seen and I think a lot came from java and C++ before it. Ironically C++ is a fantastic language now to use now while avoiding inheritance.

In the late 90s, 2000s and maybe even now, people see inheritance and think that it makes sense. They make the vehicle, the car, the sedan and then get stuck, when all they really needed was an x and y point and a velocity.

ben77994• 2 years ago

I love the way people take their narrow range of experience and over generalize it to everything. Bonus points for having a blog or maybe a patreon to tell everyone how it really is.

We have a million flavors of the month but in the end it doesn't really matter. Pick a flavor and there will be teams that are successful and teams that are not. No silver bullet will make the non-successful teams magically turn into successful ones.

"I/We failed with <insert language feature>" never generalizes to "<insert language feature>" is bad.

Then the community constantly sits there and acts like a bunch of geniuses because some programming pattern has been discovered.. except it's 50 years old.

vram223• 2 years ago

Ha ha, yes, happens all the time.

In this case, published in a book 30 years ago, at least:

https://news.ycombinator.com/item?id=40005520

reactordev• 2 years ago

Ahhh good 'ol XP/Gang of 4. Never ceases to be referenced. (for good reason)

ben77994• 2 years ago

Pretty sure it was in Effective Java and Design Patterns in Java 20+ years ago as well since Java is the language that gets picked on so frequently for this stuff.

ruszki• 2 years ago

"I/We failed with <insert language feature>" never generalizes to "<insert language feature>" is bad.

I thought the same for decades, then I met Groovy and Grails. Of course, it’s not bad in an absolute sense (IMHO that doesn’t make any sense), but when some problem can be found only at runtime, when any proper compiler would catch that compile time, it’s hard to argue that it’s a good direction. Especially when TypeScript made it quite obvious what’s possible only with simple type checking.

maleldil• 2 years ago

TypeScript made it quite obvious what’s possible only with simple type checking.

Typescript's type system is anything but simple.

d_burfoot• 2 years ago

It seems like there's a huge industry of people critiquing Java and OOP but misdiagnosing the problems as technical rather than sociological.

The immense pain and suffering that is related to Java and its ecosystem is because of the terrible organizational conditions that tend to co-occur with usage of Java. Big slow companies, long boring meetings, arguments about design patterns, "architects" who haven't written code in ten years, etc etc. Java correlates with, but does not cause, those conditions.

Another way of saying it: if Java was good enough for Nutch to use to write Minecraft, it's good enough for the vast majority of business purposes.

ldjkfkdsjnv• 2 years ago

Java complexity is also an artifact of Java being used in large complex systems. People are really complaining about how hard programming is. There are many types of large scale systems where I would only code it using the JVM, everything else is a nightmare. Big tech companies largely feel the same

ben77994• 2 years ago

So many of these articles are written by people with no CS background who then had a couple stints short stints programming and then overnight pivoted to being expert consultants. They don't really have experience building or maintaining large complex systems. I am really curious who hires them. Most of them will have significantly less experience than the senior members of a successful team, and often less relevant education.

tootie3• 2 years ago

There is an all-time great quote from Bjarne Stroustroup when asked about how many people hated C++

There are two types of programming languages: The ones people complain about and the ones nobody uses.

josephg5• 2 years ago

There are many types of large scale systems where I would only code it using the JVM, everything else is a nightmare.

I’ve seen more than one lifetime’s worth of nightmare code written in Java. I agree with the GP commenter - I don’t think the problem is Java (the language) so much as the culture surrounding it. The Java programmers I’ve worked with (all smart people) seem addicted to solving all problems my writing more Java. More interfaces (most of which just have a single implementor). More classes. More files. More abstractions. You pay a massive tax for that any time you edit your software - since inevitably you're going to end up unpicking hundreds of lines of code that could have been two if statements.

I’ve never seen this abstraction vomit disease be quite this bad in software written in other languages. You can find a bit of it in C#, C++, go and Python. But not as bad as Java. In typescript and rust, most of the code I work with focuses a lot more on directly solving the actual problem at hand.

I don’t think the problem is the language itself. Java is a fine language. But for some reason, it’s become a magnet for a certain kind of developer that I frankly never want to work with. Developers who would never use 5 lines of code when 100 would do. Developers who abstract first and understand the problem they’re solving later. It’s disgusting.

tootie3• 2 years ago

I have often observed that Java is great because it solves organizational problems. Strong and static types, interfaces and most of all, javadoc, were miraculous for conveying intent to integrators and maintainers. Even seemingly insignificant things like a naming convention for packages was extremely useful. A lot of the features trumpeted in Java when it was new, like abstract classes or checked exceptions, were adopted religiously at first but fell out of favor a long time ago. Interfaces and interface inheritance is extremely useful.

HumblyTossed• 2 years ago

Yeah, there's nothing wrong with Java the language. Java the community is what sucks. You had a few bloggers get popular and then a bunch of devs trying to make names for themselves would ape what they said, compound a few years and you have the mess people like to complain about.

Happens with a lot of language communities. C#, good grief, not much better than Java. Go(lang) community's favorite two words are "idiomatic Go". You can't read any post without seeing those two words. Go has like what, seven keywords. Let it go, man.

gorjusborg2• 2 years ago

there's a huge industry of people critiquing Java and OOP but misdiagnosing the problems as technical rather than sociological.

I totally agree. I have worked on applications that would have collapsed under their own weight if it wasn't for Java. The strong type system, stable runtime and standard library APIs, as well as great tooling allows code to live far longer than it would in some other language ecosystems.

However, don't make the mistake of dismissing all of the criticism. The truth is often nuanced, and OOP/Java does have some serious downsides and footguns. There is room for both criticism and praise.

Ultimately, great systems aren't created by throwing a language and problems at a collection of random people. Great systems happen when good decisions are consistently made over time, and those are context dependent.

not2b2• 2 years ago

I only use inheritance for what the author calls ontological inheritance. For example, I find it useful to represent expressions and statements. I prefer composition if I'm trying to reuse data structures.

feoren3• 2 years ago

But ontological inheritance is the worst kind. Because your ontology is wrong. Similar things are kinda different. Different things are kinda similar. Your ontology is based on the linguistic remnants of taxonomic garbage from hundreds of years ago. There's no shelf.

not2b2• 2 years ago

Not the way I use it, which is very limited. If the similar things are kinda different I use something else, as well as design things to expose the differences where required.

arcticbull• 2 years ago

Boring answer: Same reason we do a lot of stupid things, haha.

“If C is so unsafe and C++ is so unwieldy why does anyone use them?”

Because that’s what they learned, or because that's how the codebase is structured when you get there. When all you have is a bike you’re going to ride that shit everywhere.

You rarely if ever get the chance to start from scratch at work (where most code is written) and your job is to follow the pre-set pattern most of the time unless it becomes completely untenable. Sure, inheritance is worse in pretty much every way, but if everyone you're hiring does it that way, your codebase is built that way, etc, you're going to make the best of it because that's your job.

BatFastard2• 2 years ago

Main reason I use c++ is because it has the most mature libraries.

I gave Rust a try, and lots of nice things about it. But many of its libraries are not very mature.

josephg5• 2 years ago

What libraries do you miss from C++ that you can’t find in rust? ML is the big piece for me - there’s no mature equivalent to CUDA or PyTorch.

layer87• 2 years ago

It’s only implementation inheritance that is questionable, and the reason is that it leads to mutual dependencies on implementation details between superclass and subclass. Reasoning about correctness becomes difficult, and the superclass is very constrained in what implementation details it can change without potentially breaking some subclass.

Bertrand Meyer’s open-closed principle can be read that way: The superclass is closed to modifications. But that goes against the principle of decoupling interface from implementation: The superclass interface is now stuck with the existing superclass implementation.

nforgerit• 2 years ago

When I learned programming as a teenager, I was using one of the C++ classics which, of course, taught OOP and Inheritance as a magic silver bullet.

When I then finished the book and its examples, I wanted to do my own exercises and went through about 1-2 very painful years trying to model my things using Inheritance and totally blamed myself for being too stupid to do software development.

Only then I started searching and finding essays and blog posts of people criticizing OOP and esp. Inheritance for exactly the things I was struggling with. This felt like a relief!

My question: Why is Inheritance still taught as a silver bullet? I'm seeing university courses using Inheritance both for Domain and infrastructural code reuse at the same time. Esp. in Germany I see a lot of stupid 90s alike "programming" courses and, no shit, according code bases. It's as if they were living in a gigantic bubble.

jonnycomputer3• 2 years ago

My situation is different than a lot of others--I work mostly with code-bases I 100% control--but I just don't use inheritance all that often, and if I do, it's never deeper than one or two levels. Now, I do most of my programming in Python and in JavaScript, and I do like using python's ABCs to specify interfaces for interfaces that I expect to be implemented, but that's mostly the end of it.

ffsm8• 2 years ago

I remember the original reason for composition over inheritance to be very specific to Java: you can only inherit one class, but compose your class from multiple interfaces, each of which can have default implemented methods.

In python you've got polymorphism, mixins etc, so the reason for this suggestion doesn't really apply.

Django heavily uses inheritance for the controllers for example - and it works very well.

jonnycomputer3• 2 years ago

I don't really use mixins either, unless it's required by the libraries I'm using. Partly this is habit on my part (and I came to Python from Java). But there is a lot of functionality in python I tend to make only light use of. Like using decorators. I understand them, but they feel like magic, and imo, make code harder to understand if used too much. Same thing with inheritance and multiple inheritance.

turnsout• 2 years ago

I stopped using inheritance when Swift protocols and TypeScript interfaces came along. Although it sometimes means you need to do nasty things with generics, it beats the fragility of inheritance. With ObjC, I eventually came to hate updating superclasses, because I knew it would lead to unexpected behavior in subclasses.

tootie3• 2 years ago

Inheritance on interfaces is fantastic. Inheritance on implementations is fraught with peril. Java developers figured this out like 10 years ago.

josephg5• 2 years ago

I had the same experience. I’m a few years into using rust now - which doesn’t implement inheritance at all and I don’t miss it. In typescript I barely use classes at all. I prefer an interface paired with a constructor function.

I think it’s almost always better to first think of data as a struct, with associated code that acts on that struct. As the old saying goes, show me your data structures and not your code, and you don’t need to show me your code.

zozbot234• 2 years ago

Rust implements interface inheritance out of the box via traits, but you can also replicate something very much like implementation inheritance via phantom types/the typestate pattern. It just finds very little use in general, because it's readily apparent just how clunky that whole arrangement is.

pianoben• 2 years ago

Despite misgivings about the language as a whole, I think that Go does interfaces extremely well, and made the right choice to discard "implementation inheritance".

That said, in my time with obj-c I never really encountered the problem of fragile base-classes - protocols and categories gave us just about everything we needed. (the foundation classes use implementation inheritance extensively, but we don't typically modify those too often :) )

slaymaker1907• 2 years ago

For a really neat implementation of OOP and inheritance, I would recommend checking out Racket's class system (not to be confused with generics). It mostly solves the multiple inheritance problem by mixins and also has a great interface system.

shawn_w• 2 years ago

I find Racket's OO stuff to be awkward and cumbersome to use, and rarely a good option. One of these days I'm going to port a CLOS-inspired Scheme OO system like Guile's GOOPS to Racket...

caseysoftware• 2 years ago

The key is "prefer composition to inheritance" and dates back to Gang of Four.

The word "prefer" is critical to understand. It just means "usually choose A over B" not "B is never the right answer."

Unfortunately, since we - as an industry - like hard and fast rules, we move towards that second explanation and act like inheritance never makes sense. Like any tool, there's a time and place where it is the best tool, other times where it's a reasonable tool, and other times it's a terrible tool.

Therefore "everyone uses it" because either a) it's a reasonable approach or b) the developer doesn't know of or can't use a better one.

We should work on fixing b) instead of denying a) exists.

cogman103• 2 years ago

I agree with this sentiment but I also must say that the time's I've needed inheritance have been few and far between. I have seen really good examples where it works really well (UX is pretty common, but I've also seen really clean cases like data structures with complex interfaces and a simple abstract class).

Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined.

Where it's the worst is when someone tries to use inheritance because they notice coincidentally duplicate code. The worst hell for this is in application configuration. I've seen 5 layer deep inheritance trees to handle really basic things like "what port should this app bind to". It saved no code and introduced a bunch of complication around the transitive dependency baggage it brought on board.

IMO, configuration should always be done via composition. It's more than fine to have a bunch of smaller composable config pieces just so long as you can easily jettison the broken parts.

quaunaut5• 2 years ago

Where I think inheritance works best is when the state in base classes is limited and the interface is quiet clear. Ideally where you are meant to override is also well defined.

What benefit is inheritance providing here? What you described sounds mostly like a struct, at which point the only value the interface provides is possibly some computed fields.

dragonwriter4• 2 years ago

I agree with this sentiment but I also must say that the time’s I’ve needed inheritance have been few and far between.

You never strictly need inheritance, but strict need isn’t the criteria for whether something is a good solution (otherwise the fact that most things in programming can be done multiple ways would mean that almost nothing is ever a good solution, since there is almost always an alternative route to the same result.)

taylodl• 2 years ago

Prefer IS-A relationships where they make sense, i.e. where you expect the Liskov Substitution Principle to apply. Otherwise use composition. It's really that simple.

quaunaut5• 2 years ago

I'd be ready to agree if I could be pointed at a time that inheritance actually carries a real benefit- a time you would choose it over composition, if composition is available.

echelon• 2 years ago

There is no benefit to the "tree of life" single inheritance [1].

What you want to reach for to achieve compositional behavior or polymorphism are type classes, traits, and interfaces. They attach methods to data without the silly "Cat is an Animal, Dog is an Animal" cladistic design buffoonery.

There's nothing wrong with OO, except for inheritance-based OO.

[1] Don't get me started on multiple inheritance. Instead of solving problems, they invented them.

bsder• 2 years ago

Inheritance was a premature optimization for computers with small memory. It did its job. However, once memory got big, people forgot to throw it out.

Composition uses a lot more indirection. That's bad on modern CPUs. Pointer chasing throws out performance, so composition is not always preferred, either.

gpderetta2• 2 years ago

Composition doesn't imply pointer chasing.

In C++ there is extremely little difference between the code granted for inheritance or composition (unless you use virtual inheritance), so I have no idea what overhead you are talking about.

eddd-ddde3• 2 years ago

Simple composition, where an entity just has some components on it, can be completely "unrolled" at compile time, essentially removing all indirection as if the entity had all of the data to begin with. You don't need pointers.

For more complex composition, an ECS runtime would likely group all components of the same kind into the same place so that systems that ran with those components get even better data locality.

al2o3cr• 2 years ago

IMO it's also important to understand the context of when GoF said that - Stroustrup's C++ book was advocating for things like "class WindowWithButtonAndScrollbar inherits from Window, Button, and Scrollbar" at the time!

The GoF book itself is full of examples that use inheritance, but somehow the bumper-sticker-sized advice has taken on a life of its own.

resonious• 2 years ago

Any abstract advice that's like "do this instead of something else" looks to me like the person had a bad experience and is generalizing from it. This goes both ways, applying to both the original hype about OOP, and this sort of modern anti-OOP hype. It turns out bad code is possible regardless of which design pattern is used.

specialist• 2 years ago

Yes and:

I vaguely recall Riel's Object-Oriented Design Heuristics [1996] shared the same advice. https://www.amazon.com/Object-Oriented-Design-Heuristics-Art... https://www.oreilly.com/library/view/object-oriented-design-...

Aside: Young me obsessed over design patterns, methodologies, software engineering, SQA, etc. I had all the books. I started a design patterns study group and hosted it for a while. Now all that "wisdom" is just a bunch of old books. Somehow craftsmanship, me, or both became irrelevant.

Or maybe it was never important.

Like Alistair Cockburn opined about the failure of CASE tools, people somehow manage to ship software successful, without the benefit of all that smart stuff.

fransje26• 2 years ago

Would you happen to know any good literature with clear composition examples vs inheritance?

The C++ and Python code I see daily is fully inheritance focused, and I would like to understand how it could be done differently (or better) starting from a perspective I understand.

TheBigSalad7• 2 years ago

https://gameprogrammingpatterns.com/component.html

dragonwriter4• 2 years ago

“Prefer A over B” rules usually are problematic because what they usually mean is:

(1) There is a concrete set of cases where A is better than B. (2) But, there is also a concrete set of cases where B is better than A. (3) And, either (a) the cases where A is better than B are more common than the reverse or at least (b) people in the environment where the advice is developed are currently choosing B in cases where A is significantly better.

But, critically, “prefer A over B” does not communicate the set of cases where A is better than B or vice versa, so it tends to lead to the conditions where “prefer B over A” becomes the advice based on (1) and (2) being unchanged but (3)(b) working in the opposite direction.

fire_lake• 2 years ago

Hmmm. I have exactly zero occurrences of implementation inheritance in my code base.

feoren3• 2 years ago

Exactly. "Why does everyone use it?" is a false premise. I don't use it.

quantified• 2 years ago

Meyer also thought (for a while) that inheritance was more powerful than genericity. Later he admitted his "proof" of that was weak.

lamontcg2• 2 years ago

Inheritance is really just a public interface, a private interface and automatic delegation of those interfaces to the base class.

The problems with inheritance are:

- people shove code in the base class to dedup it without thinking about design

- people add public and protected methods without thinking about interface design

- the names of the base class and the public and protected interfaces are exactly the same thing

The last point is that if you have a FooBase class which is public then you can wind up with a bunch of List<FooBase> containers that are coupled to the base class and external methods that take FooBase parameters along with a bunch of concrete instances which are dependent upon the FooBase class protected interface and code implementation. This creates the brittle base class problem.

If instead you had an IFoo interface and only ever used List<IFoo> instead of FooBase anywhere then you could always define FooBasev2 which implemented IFoo as well and FooBase and FooBasev2 can coexist in your codebase without having to break any external consumers (open-closed principle in practice).

If base classes were only allowed to be used in inheritance and couldn't be parameters, generics, etc then that would force users to create base classes and public interfaces in pairs and would decouple their names and by writing the public interface down as its own thing developers would be more likely to focus on that design.

And really inheritance is just syntax sugar around having a component (the base class) which has automatic delegation of of the public interface and protected interface to it in the inheriting object, with so little typing that it becomes easy to not think about what you're doing -- and while reusing the same name for three different things and creating tight coupling, and you can't dependency inject different baseclasses at runtime. If languages had better terse syntax for delegation then composition would get a lot easier to use like inheritance is (which is something that Go oddly enough gets more-or-less correct, dunno why they didn't mandate piles of boilerplate for delegation like they did for error checking).

sfn423• 2 years ago

It's worth mentioning regarding the IFoo example that in a single project you can always just find/replace FooBase with IFoo or even FooBaseV2.

I feel like a lot of people blow this up like it's so e huge problem when in reality this is a pretty trivial refactor.

lamontcg2• 2 years ago

Not if you're writing a library/framework that other people use though.

If all you do is consume other people's library/frameworks then yeah, nothing really matters, do whatever you want, refactor at will.

dragonwriter4• 2 years ago

If base classes were only allowed to be used in inheritance and couldn't be parameters, generics, etc then that would force users to create base classes and public interfaces in pairs

Which, if its a common thing, suggests that there should be syntax for like:

  interface IFoo from FooBase;

That makes an interface from the public members of a class.

Or, perhaps even better, type systems should enablr.a distinction between:

class ConcreteFoo inherits FooBase; // normal implementation inheritance class ConcreteFoo implements FooBase; // is required to (compiler checked) present the public interface of FooBase, and is type-compatible, but doesn't inherit implementation

So concrete classes can also serve as interfaces, and purely abstract classes are identical to interfaces.

manuel_w2• 2 years ago

If base classes were only allowed to be used in inheritance and couldn't be parameters, generics, etc then that would force users to create base classes and public interfaces in pairs and would decouple their names and by writing the public interface down as its own thing developers would be more likely to focus on that design.

I agree and like this principle, however, but what would be the difference between the base class and a mixin class then?

manuel_w2• 2 years ago

TIL that in Python you cannot use a mixin class to provide implementation for an abstract base class that defines the interface.

In other words, in the inheritance tree, the class providing the common implementation must sit between the interface class and the concrete classes.

m463• 2 years ago

I found multiple inheritance kind of fun when I was first exploring python.

Then, madness...

wakawaka28• 2 years ago

Because it's not actually so bad ;)

GendingMachine• 2 years ago

As a programmer with likely less experience than most of these commenters, the main question that always feels under addressed in these kinds of posts is that of code deduplication.

Most specifically, often when encountering a situation in which I have two slightly different classes/types that need to be polymorphic with each other, all the standard non-inheritance based approaches seem to require a lot of outright identical code implementing a shared interface, a bunch of boilerplate composition proxy methods that just point to methods in a composed class, or weird and obscure language features that never really feel like the "intended" approach.

Typescript especially seems to demand really awkward and obtuse implementations of basic mixins or abstract classes and the like, I always feel like I'm missing the more "intended" approach whenever I try to share code between similar classes.

Often discussions around this are awash with talk of traits and delegates and other cool features that seem to only exist in a handful of languages, and never the ones I happen to be required to use at that given moment.

contravariant• 2 years ago

It's always possible to 'deconstruct' objects with methods into just dumb structs with functions acting on them. This is the direction Julia takes for instance.

One advantage of this is that it exposes that 'inheriting' a method is really just applying the same base function to all classes that support a particular interface. You can override a method by specialising the function for a subinterface. This interface can just be a marker that says 'this struct has these fields, and semantically is a 'IMyInterface').

Of course object oriented programming languages tend to encourage private and protected properties and such, which force all of this to take place inside the class. At first I though that that was the best way to avoid a mess, but it prevents you from doing this, possibly leading to more code duplication. And after some more experience with python there's something to be said for python's approach of just using name conventions to point out when to be careful.

chuckadams2• 2 years ago

Typescript is best when you don't use `class` or `this` at all, but instead return object literals of static closures. In other words, more like this:

    function makeCounter(initial = 0) {
        let count = initial;
        function get() { return count }
        function inc() { count += 1 }
        function dec() { count -= 1 } 
        return {get, inc, dec}
     }

      // works just like a normal object
      const ctr1 = makeCounter(); 
      ctr1.inc()

      // but this works too.  try doing this with a class instance.
      const {get, inc} = makeCounter() 
      inc()

This is the typical style of most VueJS code (though it would replace count with a ref and probably call the function `useCounter`). TypeScript is smart enough that it can infer interfaces and even classes from such literals should you go that way, full support for substitutability checking and all.

jokethrowaway• 2 years ago

I look mostly at JS and some Rust codebases and almost nobody uses inheritance!

I believe it doesn't make any sense, you can use different patterns to have the benefits without creating a complicated type hierarchy where state and functions are mixed across different files.

Whenever I would use inheritance I use the builder pattern.

revskill• 2 years ago

Use inheritance as vomposition with parent ?

pyuser583• 2 years ago

A lot of it goes back to Java. Java has .class files, not .instance files.

throwiforgtnlzy• 2 years ago

While I don't use the ecosystem, I like the way Go approaches it with interfaces by being minimal, expressive, and flexible. It something works like something else according to a minimal specification, it's the same. There's no sealing off things or top-down mandates that require changes to other people's code. Rust traits aren't exactly the same because they require changes to everyone's code to follow an exact model that cannot be retrofitted to existing code without additional work. One downside (it may not be the case today) with the Go model is requiring a type to fulfill one or more interfaces requires additional hoops such as no-op init() interface assertions.

reify• 2 years ago

If.......... Why......... Everyone....

click click click click click click click click click click click click click click click click click click click click click bait

hnycuc23• 2 years ago

We don't use inheritance anymore. In all the years building small and hughe software solutions with small and larger teams I've never experience any real scaling, maintenance or resilience benefit. Even for documentation it is more a pain for new devs onboarded than an advance. Patterns,DRY, DI, IOC, MS, ES, IO are best to build with these scopes in head.

silent_cal• 2 years ago

Nerds make things complicated, no matter what. It is their fundamental impulse that cannot be tamed, like the scorpion who must sting the frog that carries it across the river.

lucasyvas• 2 years ago

There is no valid use case I've ever seen where inheritance was better than composition (that does not mean a use case does not exist, but evidence is mounting against it). I would say it's used because every language made a poor decision by building that in as the way to encapsulate reusable logic. i.e., a mistake.

Some APIs may expose themselves as requiring you extend a base class, and in that case you might as well do what the library author said. But overall? Yes, some things can work well with inheritance (eg. classical UI frameworks), but these are often equally good with a composition based API.

One job I was at I added a lint rule to flag `extends` as an error. You would need to add a comment to justify why you were using inheritance - it went over more favourably than I expected. I think I would suggest this for any new projects using a language that supports inheritance - discourage it with automation, but allow really good reasoning to prevail in review. It is the worse solution at least 99% of the time because it requires you predict a future that is painful to change.

TheBigSalad7• 2 years ago

Composition implies a level of complexity. There may be a near infinite number of permutations of things that can be combined. If in reality there are only a fixed set of variations, inheritance may model your system in a tighter way. The benefit can be simplicity.

Capricorn24817• 2 years ago

Composition implies a level of complexity

How?

Supermancho3• 2 years ago

Inheritance is unidirectional composition. I'm combining the parent with the child.

Making the relationship simple to create and hard to complicate, is why it endures, afaik.

davidalayachew3• 2 years ago

I can think of one. For Java at least.

Imagine that I have a class that has 15 methods -- 14 are a perfect fit as is, but 1 of them needs to be completely overwritten.

If I were to do inheritance, I would do `extends` on the class, and then `@Override` the offending method. Problem solved.

If I were to do composition, I could use the Delegation Pattern from the Gang of Four, but that would require me to write 14 do-nothing methods just to be able to override the one.

In general, composition has more use than inheritance. However, inheritance has a non-zero number of use cases where it is a better choice than composition.

hnick• 2 years ago

It really depends on what the code variation is, and it can often be a code smell, but I like just adding a flag to the method for simpler cases of this. No complexity or overhead, easy to reason and debug, and you can retain the current method signature with a default-case call to the new method, so no other refactoring required.

It can be inelegant, clunky, and terrible practice if you're doing two totally different things in the method, but I've had a lot of cases recently where it was a nice simple solution that made sense in the context we used it.

For me, one time I like that we use simple OO is a 'DeletedMyClass' extending 'MyClass'- it does everything the same, just has a DeletedDateTime property. A few pages will do an 'is' check (we use C#) and render certain things differently, but apart from that, they both get passed around interchangeably. You could argue you could add an IsDeleted flag, but the default case is that most things we deal with are not deleted, and they shouldn't have to even know about that concept. So to me this is a very useful minimal case of OO.

mrkeen7• 2 years ago

I have just the one use case: to escape out of framework/annotation hell.

Say I have a well-designed, self-contained BusinessService class which is perfectly unit-testable.

Then someone comes along and sprinkles some @Magic bullshit on it. Now its true behaviour won't be exercised in plain junit - you need custom test runners with class-path scanning and late-binding configuration ("The gorilla holding the banana and the rest of the jungle" in Joe Armstrong speak).

If you want to reclaim your unit-testable class, you can divide it into two: SpringBusinessService extends BusinessService. Move all the Spring dependencies out of the latter into the former.

Now you get the best of both worlds - clean, unit-testable logic, and a service that Spring can obfuscate with middleware to produce 200-line-long stacktraces after a lengthy startup.

xorvoid• 2 years ago

Depends what language you're using and what polymorphism features it has...

C - You don't use inheritance because it literal has none, but you can handroll dynamic dispatch (interface style Abstract Base Classes)

Rust - Also doesn't have it and people seem perfectly happy with generics, sum-types, and `dyn Trait`

da39a3ee• 2 years ago

One thing that bothers me is when people refer to languages like Go and Rust as "not object-oriented". Of course they are object oriented; Go and Rust programs consist of struct definitions to which you associate methods, giving rise to individually instantiatable objects with custom behavior, and you use these objects to model entities in your problem domain. This is object-orientation.

Where they differ from OO languages such as Java and Python is of course that they avoid traditional inheritance, offering more restricted inheritance-adjacent features (typeclasses/traits/interfaces and struct embedding).

Like many others I find Go disappointing in many regards. (Although Go's channels, goroutines, select, and implicit interfaces are beautiful). One disappointment is the way that methods are not indented or nested within the struct definition/interface that they are defined on. This is, IMO, a silly fig-leaf that is attempting to make the language look "not OO" in a superficial manner, but all it ends up doing is making it hard to see where your implementation of one interface ends and another starts.

sporkland• 2 years ago

In my mind, the more generic rule underneath these rules is you want to be able to comprehend what a unit is doing without jumping between a massive number or files or contexts. Inheritance hierarchies with shared state and overrides means you need to understand multiple files and their interactions vs interfaces and composition tend to allow for fairly understandable units with clear interactions.

The big problem these deep inheritance hierarchies cause is mediocre programmers often think they're writing good code (often high focus on maximal reuse) but the interfaces and clarity are terrible.

beryilma• 2 years ago

I don't think that inheritance is bad per se. AbstractWindowButtonManagerFactory type of inheritance is bad. I think the reason is that people are not just good at constructing hierarchical relationships between abstract concepts. And once you construct such an elaborate hierarchy, it becomes very hard to correct things after the fact. So you end up with a mess as people add more functionality on top of an already ill-conceived structure.

If Inheritance is so bad, why does everyone use it?

Related Stories