public interface ICanTravelThroughTheAir
{

}

public class Flea : ICanTravelThroughTheAir
{

}

public class AircraftCarrier
{
  private readonly List<ICanTravelThroughTheAir> _aircraft = new();

  public void AddAircraft(ICanTravelThroughTheAir flyingThing)
  {
    _aircraft.Add(flyingThing);
  }
}

public class Dog : AircraftCarrier
{
    public void Woof()
    {
        Console.WriteLine("Bitch I'm an aircraft carrier!");
    }
}

public static class Program
{
  public int Main(string[] args)
  {
    var dog = new Dog();
    
    for (var i = 0; i < 10000; i++)
    {
        dog.AddAircraft(new Flea());
    }

    dog.Woof();
  }
}

This is exactly how I feel too. A little bit of repetition is totally worth it, versus having inappropriate coupling, or code that jumps in and out of parent/child classes everywhere so you can hardly keep it in your head what's going on.

I freely accept that I AM a mediocre dev, but if that lends me to prefer code that is comprehensible and maintainable then I think being mediocre is doing my team a favour, honestly.

PTSD flashbacks to the codebase I started on in 2008 which had... I don't even remember. Like six or seven levels. Fucking nightmare. I did a printout of the analysis Doxygen gave me and it ended up as a 4x3 meters poster ;_;

When I first started using Go I bemoaned the lack of true inheritance and classes. Now I love it.

But if I have to make an Array I have to inherit from Indexable which inherits from Collection which inherits from Object! How else am I supposed to implement an Array?

@mesamunefire
@tiramichu

I totally agree on this. I found that often things that appeared to need inheritance at first glance often didn't if I gave deeper thought to it.

Granted I was working on much smaller projects rather than crazy huge multi team enterprise apps, but I'd guess that even then this is a good "rule of thumb".

composition can help with all of that. factories, strategies, injections are all composition patterns that work fine.

business logic that repeats? extract it to it's own thing (class, function, etc) and pass it as a param to the supposed childs.

mvc? controllers don't need to extend anything, just have them accept the framework through the constructor and request and response as args. views? same. models? perhaps only if doing an active record, but a repo pattern with plain objects is a good pattern too.

I never seen a clean inheritance implementation for a decently sized problem. it mostly works for tiny ones.

It's wildly useful, when you store a lot of similar stuff, or treat a lot of similar stuff etc.

Like a GUI, a rendering engine or a scientific soft. Video games, any soft with users, and so on.

I get that people misuse it but for me it's wild that people think you should like program without it, like at all cost.

We use it a lot when we have a solution that works for 95% of customers and a few need random things.

Else we will have multiple markets changing the same function with a thousand if else

Main issue is that makes it so that some functions are never generalized, like when customer A wanted to use an equal filter, customer B wanted a IN filter, and the rest have no filtering capability at all.

Was gonna say just this. Inheritance is powerful but something to reach for sparingly. 80% of the time aggregation and composition can solve the problems.

I’ve cleaned up too many inheritance nightmares in my day from people who insisted inheritance was the way to go.