Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

If you store optional functionality of a base class in a secondary class, should the secondary class subclass the base class?

I know the title is probably a bit confusing, so let me give you an example. Suppose you have a base class Base which is intended to be subclassed to create more complex objects. But you also have optional functionality that you don't need for every subclass, so you put it in a secondary class OptionalStuffA that is always intended to be subclassed together with the base class. Should you also make that secondary class a subclass of Base?

This is of course only relevant if you have more than one OptionalStuff class and you want to combine them in different ways, because otherwise you don't need to subclass both Base and OptionalStuffA (and just have OptionalStuffA be a subclass of Base so you only need to subclass OptionalStuffA). I understand that it shouldn't make a difference for the MRO if Base is inherited from more than once, but I'm not sure if there are any drawbacks to making all the secondary classes inherit from Base.

Below is an example scenario. I've also thrown in the QObject class as a 'third party' token class whose functionality is necessary for one of the secondary classes to work. Where do I subclass it? The example below shows how I've done it so far, but I doubt this is the way to go.

from PyQt5.QtCore import QObject

class Base:
    def __init__(self):
        self._basic_stuff = None

    def reset(self):
        self._basic_stuff = None


class OptionalStuffA:
    def __init__(self):
        super().__init__()
        self._optional_stuff_a = None

    def reset(self):
        if hasattr(super(), 'reset'):
            super().reset()
        self._optional_stuff_a = None

    def do_stuff_that_only_works_if_my_children_also_inherited_from_Base(self):
        self._basic_stuff = not None


class OptionalStuffB:
    def __init__(self):
        super().__init__()
        self._optional_stuff_b = None

    def reset(self):
        if hasattr(super(), 'reset'):
            super().reset()
        self._optional_stuff_b = None

    def do_stuff_that_only_works_if_my_children_also_inherited_from_QObject(self):
        print(self.objectName())


class ClassThatIsActuallyUsed(Base, OptionalStuffA, OptionalStuffB, QObject):
    def __init__(self):
        super().__init__()
        self._unique_stuff = None

    def reset(self):
        if hasattr(super(), 'reset'):
            super().reset()
        self._unique_stuff = None
like image 795
mapf Avatar asked Dec 17 '20 11:12

mapf


Video Answer


2 Answers

What I can get from your problem is that you want to have different functions and properties based on different condition, that sounds like good reason to use MetaClass. It all depends how complex your each class is, and what are you building, if it is for some library or API then MetaClass can do magic if used rightly.

MetaClass is perfect to add functions and property to the class based on some sort of condition, you just have to add all your subclass function into one meta class and add that MetaClass to your main class

From Where to start

you can read about MetaClass here, or you can watch it here. After you have better understanding about MetaClass see the source code of Django ModelForm from here and here, but before that take a brief look on how the Django Form works from outside this will give You an idea on how to implement it.

This is how I would implement it.

#You can also inherit it from other MetaClass but type has to be top of inheritance
class meta_class(type):
    # create class based on condition

    """
    msc: meta_class, behaves much like self (not exactly sure).
    name: name of the new class (ClassThatIsActuallyUsed).
    base: base of the new class (Base).
    attrs: attrs of the new class (Meta,...).
    """

    def __new__(mcs, name, bases, attrs):
        meta = attrs.get('Meta')
        if(meta.optionA){
            attrs['reset'] = resetA
        }if(meta.optionB){
            attrs['reset'] = resetB
        }if(meta.optionC){
            attrs['reset'] = resetC
        }
        if("QObject" in bases){
            attrs['do_stuff_that_only_works_if_my_children_also_inherited_from_QObject'] = functionA
        }
        return type(name, bases, attrs)


class Base(metaclass=meta_class): #you can also pass kwargs to metaclass here

    #define some common functions here
    class Meta:
        # Set default values here for the class
        optionA = False
        optionB = False
        optionC = False


class ClassThatIsActuallyUsed(Base):
    class Meta:
        optionA = True
        # optionB is False by default
        optionC = True

EDIT: Elaborated on how to implement MetaClass.

like image 137
wetler Avatar answered Nov 11 '22 04:11

wetler


Let me start with another alternative. In the example below the Base.foo method is a plain identity function, but options can override that.

class Base:
    def foo(self, x):
        return x

class OptionDouble:
    def foo(self, x): 
        x *= 2  # preprocess example
        return super().foo(x)

class OptionHex:
    def foo(self, x): 
        result = super().foo(x)
        return hex(result)  # postprocess example

class Combined(OptionDouble, OptionHex, Base):
    pass

b = Base()
print(b.foo(10)) # 10

c = Combined()
print(c.foo(10)) # 2x10 = 20, as hex string: "0x14"

The key is that in the definition of the Combined's bases are Options specified before the Base:

class Combined(OptionDouble, OptionHex, Base):

Read the class names left-to right and in this simple case this is the order in which foo() implementations are ordered. It is called the method resolution order (MRO). It also defines what exactly super() means in particular classes and that is important, because Options are written as wrappers around the super() implementation

If you do it the other way around, it won't work:

class Combined(Base, OptionDouble, OptionHex):
    pass

c = Combined()
print(Combined.__mro__)
print(c.foo(10))  # 10, options not effective!

In this case the Base implementation is called first and it directly returns the result.

You could take care of the correct base order manually or you could write a function that checks it. It walks through the MRO list and once it sees the Base it will not allow an Option after it.

class Base:
    def __init_subclass__(cls, *args, **kwargs):
        super().__init_subclass__(*args, **kwargs)
        base_seen = False
        for mr in cls.__mro__:
            if base_seen:
                if issubclass(mr, Option):
                    raise TypeError( f"The order of {cls.__name__} base classes is incorrect")
            elif mr is Base:
                base_seen = True

    def foo(self, x): 
        return x

class Option:
    pass

class OptionDouble(Option):
    ... 

class OptionHex(Option):
    ... 

Now to answer your comment. I wrote that @wettler's approach could be simplified. I meant something like this:

class Base:
    def __init_subclass__(cls, *args, **kwargs):
        super().__init_subclass__(*args, **kwargs)
        print("options for the class", cls.__name__)
        print('A', cls.optionA)
        print('B', cls.optionB)
        print('C', cls.optionC)
        # ... modify the class according to the options ...

        bases = cls.__bases__
        # ... check if QObject is present in bases ...

    # defaults
    optionA = False
    optionB = False
    optionC = False


class ClassThatIsActuallyUsed(Base):
    optionA = True
    optionC = True

This demo will print:

options for the class ClassThatIsActuallyUsed
A True
B False
C True
like image 27
VPfB Avatar answered Nov 11 '22 04:11

VPfB