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?
2 Answers 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.
-
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?pstatix– pstatix11/08/2019 15:05:03Commented Nov 8, 2019 at 15:05
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.
-
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?pstatix– pstatix11/07/2019 20:39:08Commented Nov 7, 2019 at 20:39
Explore related questions
See similar questions with these tags.
Parent
where those common attributes are placed?ParentA
.