Do you use inheritance when programming?

The Linux Kernel codebase is full of inheritance, if you are open to understand how inheritance gets implemented in plain C.

A graphics driver for a certain vendor inherits from the DRM class, which inherits from PCI, which inherits from the Device class. Structs which embeds structs which embed structs, and you can access the base classes using the container_of() macro.

As for me, I particularly abuse inheritance in C++, although I a lot of cases I end up replacing it with template programming. To the luck of society, most of the code where I abuse templates and inheritance is not used by anybody else except for me.

Only when there's a blatantly obvious reason to. The example that immediately comes to mind is GUI elements: there's both a lot of code that many similar-but-different class instances share, and a strong "is-a" semantic. Even then, most of the hierarchy is only 1 level deep (Button -> Element).

Flat is better than nested.

I was doing some genetic programming research. Inheritance was beautiful, because I could have an Instruction base class, and all the possible specific instructions were derived from that. The execution engine and reproduction stuff could just deal with Instructions, without knowing any specifics about any of them. Each specific instruction knew how to execute itself and how to copy itself. It made things so simple.

When there's a good reason to use it, use it. If there's not, don't. Nobody's forcing you to use it.

I most of the time writing crummy firmware in C. You can do inheritance in C and it always feels like an antipattern. In C# mostly never unless a library requires it. Especially since C# has generics without type erasure.

I think inheritance is a bad solution to the problem of wanting to call foo's baz() method or access a property. Been way long since I poked at Ruby or Javascript but I thought those languages allow you to do that without inheritance. If so why would you even bother 99.9% of the time.

Occasionally for edge cases in Java, but generally I go for composition with interfaces.

Never ever do I do this for tables / entities or controllers. Things get fragile fast with that.

Inheritance can be clean and expressive when used diligently. If you wish to express a tight cohesion between classes with default functionality (especially when it pertains to instance variables), an abstract parent class can keep the shared logic in a single place. I run into this often when dealing with Android UI code which tends to involve many "variations on a theme" classes.

All the time. The easiest example is that we have a search box on the top of every screen that makes the same API calls and has the same results (wiki-style app). The code also shares a lot of similar functionality that's on almost every screen, like displaying a loading prompt. We put these in some base classes.

Larger codebases also use them extensively. I worked on a project which had multi-millions in funding. Basically it was video streaming functionality, dealt with DRM/CA, rewind, optimization, all that done. We were on the UI team, meaning we build a different UI based for a specific client brand, utilizing the same code as in done in many countries.

With those, you don't build a custom code from scratch. You just inherit and modify.

I only use them heavily in Java though, never JavaScript, even though we built that video streaming app in both. It's just a different paradigm. I can live fine without inheritance though. It's just a nice to have.

This has been great feedback. To summarize, I heard people use inheritance because its the API of a chosen framework and in rare cases when it proves convenient like UI Elements.

I also remembered that unit test suites are an instance when I've enjoyed inheritance.

But it sounds like most people here do not use inheritance in the business logic of their apps/systems. Composition and dependency injection do the job of sharing code without sacrificing comprehensibility.

Thanks everyone! This all matches my experience as well. I just wanted to make sure I wasn't missing something life-changing!

Yes. The textbook examples really don't do practical applications justice though, e.g.:

  shape
  
  ...
  
  circle extends shape

I find it very useful to extend classes in an existing framework or system with a new functionality specific for my particular problem.

For a general example, sub-typing exceptions is useful.

One-level deep inheritance can be great for abstracting common functionality, and multi-level inheritance sometimes makes sense in very large applications. What you want to watch out for is multi-level inheritance with an inheritance hierarchy that parallels some hierarchy that is merely incidental to the code's functionality, like the page navigation hierarchy.

I would say that having a multi-level inheritance hierarchy with greater than "constant" number of children per parent in one package is a code smell.

I’ve recently been doing it. We use Dapper ORM. It’s super light weight and easiest to make classes that map 1-1 with database columns since Dapper does reflection to match up property names and column headers.

I’ve found the best way to add some extra view data to a class that is directly backed from a DB table is to inherit from the 1-1 class that Dapper uses, and just add the extra data in the child class.

That way dapper doesn’t get confused by properties not mapped to the database table, but I get to use the extra data properties in my view.

Inheritance of classes with behaviours has only ever brought me pain and suffering.

Though sometimes I'll have an inheritance tree of interfaces, which is pretty easy to manage.

The best way I've found to share behaviour is dependency injection, it's more flexible and consistent than shared methods in a parent class. But you need a DI framework to manage all the instantiation, which can add undesired complexity.

I rarely write my own class and then use that as a parent of a new class. But I very frequently write a class that inherits from a parent class when I use a framework.

When I teach inheritance to students, it’s not usually with the mindset that “You’ll use inheritance a lot in the original code you write.” The mindset I teach with is, “You’ll see inheritance often in the codebases you work with.”

Sometimes, but not frequently. I'll write abstract classes and inherit from those occasionally.

The only times in recent memory where I have inherited a concrete class from another concrete class was to add functionality to an existing program without starting a massive refactor.

Very very rarely, and only when it is obvious. I could live without it, I'd say.

And the following question is do you honour LSP (Liskov substitution principle)

In other words can you freely swap out derived classes you didn’t know about when you wrote the base class.

To understand where and why to use inheritance, read about the design patterns first. But anyway it depends on your problem and language you use.

Only when the framework I'm using demands it. The oft-cited wisdom of "composition over inheritance" rings true, in my experience.

Yes. While submitting technical tests for backward job interviews. Other than that, nahhh not really. It’s a hangover from OOP 1.0

Typescript and Golang interfaces extend each other a lot via inheritance, from my experience in various codebases.

No I don't. I can't remember or think of an example where I used it.

Only if I am going to have like ten different children