0

I need to extend the parent classes of two child classes by adding shared methods to them. Starting with the initial definitions of the child classes:

class ChildA(ParentA):
    pass

class ChildB(ParentB):
    pass

The parent classes behave similarly but their implementations are different, thus each child class must inherit separately from them. For example, ParentA has behavior that when destroyed terminates the program, but ParentB does not. However, the parent classes have attributes that both child classes would need to perform operations on. There are 5 methods I need to add, that both child classes use regularly. I could define each method in the child classes but the code is identical and thus redundant. From this I believe a "mixin" class would serve well:

class Mixin:
    def some_method(self):
        self.my_attribute.do_something() # my_attribute exists in ParentA and Parent B

class ChildA(ParentA, Mixin):
    pass

class ChildB(ParentB, Mixin):
    pass

I've never done this, and it appears to me that I may be violating some rule by having a class defining methods that use attributes of a class that inherits from itself. This dependency could cause undefined behavior if somebody where to use the Mixin class for another child class that does not also inherit from a parent class that makes these attributes available.

Is there a way to secure this approach? Is this the best approach? Is there a name for this type of class design/inheritance? Am I breaking any major design rules/principles?

  • 1
    Why do ParentA and ParentB not inherit both from a base class Parent where those common attributes are placed? – Doc Brown Nov 7 '19 at 19:08
  • Although they share similar methods, there is behavior in the classes that make them unable to inherit from a shared class. – datta Nov 7 '19 at 20:34
  • Can you elaborate on this? I have no idea which kind of behaviour could forbid this. – Doc Brown Nov 7 '19 at 21:02
  • @DocBrown Both parent classes produce windows managed by the OS window manager. However, one parent closes all windows when closed (its the root applicaiton window) where as the other parent are all higher level windows (can be closed and application still runs). The application shouldnt have, at any time, more than one instance of type ParentA. – datta Nov 7 '19 at 21:13
  • @DocBrown Because of this, and that both parents use native OS windows but serve entirely different purposes, they have access to the same attributes (such as width, position, color, etc.). The easiest solution is to just duplicate the methods in each child class, I just thought a mixin would be more idomatic; that was until I realied it assumes that the attributes will be present since it doesent inherit from the other parents. – datta Nov 7 '19 at 21:15
2

I am reading you descend from OS window classes and then start adding your own, not window related behavior to them. Then when it is time to clean up you find stuff is destroyed you did not mean to destroy.

The problem seems to be your choice to jump onto a vehicle just because it was available, not because your created behavior had any place there.

Stop descending from those OS windows and create your own class tree. Then you may want to add your class instances as members to those windows you must have anyway. And you could destroy any member without bringing down anything unrelated.

Your violation would be that you are ignoring the is-a rule for inheritance. Your A and B are not windows. Technically they are because you descended them from windows but logically they are not.

|improve this answer|||||
  • I am adding window related behavior though. The behavior to be added uses methods available by both A and B. I will only ever need one A and n B. The question is: is it wrong that a mixin classes uses attributes of its children? – datta Nov 8 '19 at 15:05
1

You definitely do not want parent classes depending on/using a child class's attributes.

If two child classes need X methods that are exactly the same, put them in the parent class. If one child class needs to do something else, it can override the parent class's method.

|improve this answer|||||
  • A better description would be that a parent class that has a child of multiple inheritence needs to access methods of the other parent. Should a mixin class not touch the attributes of another parent? Analgous to a dual income family, should the father not touch the money the mother makes, yet the child has access to both? – datta Nov 7 '19 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.