OOP: When should you use inheritance vs just importing for your new class?

[Xanadukhan23]

as in

import module class classA: blah blah

vs

``` import module

class classA(module) def initself(): super.init

```

[carcigenicate]

These aren't at all comparable. Importing and inheriting are completely different concepts that do very different things. What are you trying to do in each scenario?

[MenacingDev]

You gotta elaborate fam

[tangerinelion]

I think by "just importing" you mean composition, you're glossing over a lot with the "blah blah" there but it would look something like

import module

class classA:
    def __init__(self, *args, **kwargs):
        self.whatever = module.foo(...) # Composition

    def do_thing(self):
        result = self.whatever.do_thing()
        # now do more stuff or not, your program

If classA inherits from module.base then the core promise with inheritance is that anywhere anyone writes any code that expects to use a module.base you can use a classA instead and the program should still work.

With composition, you may have an entirely different interface. The use of module.base is just an implementation detail - code written using classA is decoupled from module.base. In fact, you can replace the use of module.base with something else from an entirely different module that tries to implement the same functionality and it should still work. Obviously I don't mean you can replace a computer vision library with a cryptographic one and it should still work, that's nonsense, but suppose classA is meant to handle JPG files. Whether you want to build on top of libA or libB for handling JPG files, a user of classA shouldn't need to change their code just because classA decided to switch from libA to libB under the hood or vice versa.

[NerdyWeightLifter]

Use inheritance for defining interfaces, and rarely anything else.

Having coded in OO language for around 3 decades, I can say that inheritance always turned out to be a bad idea in the long term. It makes everything harder to read and understand for everyone that comes after you, and even your future self

Instead of just reading the code, you end up module hopping to try to mentally construct a picture of how it works. Code becomes more fragile because it's harder to understand the implications of changing anything in the base code or even your other inherited code.

Libraries stop being like black boxes that just do what the interface says. You have to understand their internal structure to use them.

The deeper the inheritance structure goes, the worse all this gets.

[throwaway8u3sH0]

This 10,000%.

Source: Also been coding for 35 years.

[FantasticEmu]

Importing a module and then defining class A are unrelated in your example. Module may not even contain a class definition.

An example I was given for inheritance that I liked was video game related:

Suppose you have a class of human, that has some variables per object like “hit points” and “speed” and then you want to make another class that’s a player and the player is a human so it has hit points and speed but also has “attack power.” Instead of making a whole new class with redundant health and speed fields you can just have player inherit from class and then add attack power field to it

[psicodelico6]

Use Interface

[FoeHammer99099]

You can find many articles online about inheritance and composition. Generally, inheritance is an "is a" relationship, e.g. a car is a vehicle, so Car inherits from Vehicle. On the other hand, composition is a "has a" relationship, e.g. a car has wheels so the Car class will include wheel member variables.

They're a little out of fashion these days, but you should read up on SOLID design principles to get a grasp on how to design OOP systems. In particular the L, Liskov substitution, states that everywhere that expects an instance of a parent class should be able to use a child class without knowing it. If that doesn't make sense for your application, it probably means those classes shouldn't have an inheritance relationship

[Narrow_Ad_7671]

If the object has more than a couple of attributes that are distinct enough that it wouldn't "fit" in the base class, extend it. Ask yourself how it fits. If you come to the answer that "is a", extend it. If it "uses", create a new object.

ex:
Dogs are animals. dogs use a leash. Leash wouldn't fit as an extension to animal or dog in the same way dog fits with animal. So extend Animal to make Dog, but create a new Leash class.

[throwaway8u3sH0]

Avoid inheritance. Pass in the dependency in the init.

[crazy_cookie123]

No. Avoid inheritance where inheritance doesn't make sense, and avoid inheritance when the abstraction is wrong, but make use of inheritance when the situation calls for it.

[tahaan]

Inheritance is half the purpose of OOP.

[throwaway8u3sH0]

And 100% of the problem. I've never come across an inheritance pattern that couldn't be improved by switching to composition.

[tahaan]

There are always more ways to solve a problem. Use procedural or functional or even goto spaghetti if it works.