Design pattern for interface for different classes - python

I am seeking the right design pattern to implement interface in a class setting.
My file structure like follows:
models: which contains different models written in classes, say Model, subModelA, subModelB, subsubModelC etc.
calculators: which contains different calculator tools for each models. Note the calculator will need to import model attributes for computation.
My question is how should I structure my calculator file so as to follow the structure of models.
My original attempt is to write a ABC class for my calculator and then for each subModel class in model I write a respective subCalculator subclass to implement. However this does not seem to fully exploit the prescribed class structure in model.
Some baby example of my attempt:
# in model.py
class model(object):
def __init__(self,attr1):
self.attr1 = attr1
class submodel(model):
def __init__(self, attr1, attr2):
super().__init__(attr1)
self.attr2
# in calculator.py
from model import model
class calculator(abc.ABC):
#staticmethod
#abc.abstractmethod
def calculate(model):
return model.attr1 ** 2
class subcalculator(calculator):
def calculate(model):
y = super(subcalculator, subcalculator).calculate(model)
return y + model.attr2 ** 3
I have surveyed some design pattern catalogs as listed in here, and strategy seems to be the right pattern. But the baby example there does not address my concern, as I would hope to use class structure in model file.
I'd hope someone can give me a more full-fledged example in such case. My thanks in advance.

So you can separate models and calculators like this:
# in model.py
import calculator as cal
class model(object):
def __init__(self,attr1):
self.attr1 = attr1
def calculate(self):
return cal.defaultCalc(self)
class submodel(model):
def __init__(self, attr1, attr2):
super().__init__(attr1)
self.attr2
def calculate(self):
return cal.subCalc(self)
# in calculator.py
def defaultCalc(model):
return model.attr1 ** 2
def subCalc(model):
return defaultCalc(model) + model.attr2 ** 3

Related

What's the correct way to use helpers to extend functionality in Django models?

I'm adding some extended functionallity to my models in Django. In order to not overload the model root interface (and file), i'm using some helpers as attributes of the model.
What i want is to group the methods and properties into this helpers, and what i want is something like:
class Product(models.Model):
downloads = DownloadsHelper()
# ....
pass
p = Product.objects.first()
p.downloads.files_count(p)
p.downloads.reset_permissions(p)
# ...
In order to not to have to pass the instance to the helper each time, I could use another approach.
class Product(models.Model):
def __init__(self, *args, **kwargs):
super(Product, self).__init__(*args, **kwargs)
self.downloads = DownloadsHelper(self)
self.shipping = ShippingHelper(self)
p = Product.objects.first()
p.downloads.files_count
p.downloads.reset_permissions()
And finally, a more python-generic/conceptual way to do this stuff would be like:
class Helper:
def __init__(self, helped):
self.helped = helped
class Helper1(Helper):
attribute_name = 'helloing'
def hola(self): print("hola")
class Helper2(Helper):
attribute_name = 'goodbying'
def chau(self): print("chau")
class Helped:
def __init__(self):
self._install_helpers()
def _install_helpers(self):
for helper in self.helpers:
setattr(self, helper.attribute_name, helper(self))
class MyHelped(Helped):
helpers = [Helper1, Helper2]
h = MyHelped()
h.helloing.hola()
h.goodbying.chau()
And the question is: Is this last approach a correct way /good practice to do the stuff from a pythonic-OOP and "Djangoid" point of view. Has this any problem?
Thanks for reading!
Maybe you did not show the full complexity for your methods, but from what you showed it could be simplified a bit.
You could use "direct/simple" inheritance, and if you have a lot of methods then for organization you could maybe prefix the method names with h1_ and h2_ to indicate which helper class they are from:
from django.db import models
class Helper1:
def h1_hola(self):
print("hola")
class Helper2:
def h2_chau(self):
print("chau")
class MyHelped(Helper1, Helper2, models.Model):
pass
h = MyHelped()
h.h1_hola()
h.h2_chau()
Would this simpler approach be sufficient for your specific needs?

Choosing between base class or extended class - Python

I have a Python library which will be used by other people:
class BaseClassA:
class BaseClassB:
def func0(self):
this.class_a_obj = BaseClassA()
BaseClassB creates a BaseClassA object and stores a pointer. This is an issue because I want to allow the user to extend my library classes:
class ExtendClassA(BaseClassA):
And my library should choose the extended class (ExtendClassA) instead of the base class (BaseClassA) in the func0 method.
Above is a very simple example my problem statement. In reality I have 10ish classes where extending/creation happens. I want to avoid the user having to rewrite func0 in an extended BaseClassB to support the new ExtendClassA class they created.
I'm reaching out to the stack overflow community to see what solutions other people have implemented for issues like this. My initial thought is to have a global dict which 'registers' class types/constructors and classes would get the class constructors from the global dict. When a user wants to extend a class they would replace the class in the dict with the new class.
Library code:
global lib_class_dict
lib_class_dict['ClassA'] = BaseClassA()
lib_class_dict['ClassB'] = BaseClassB()
class BaseClassA:
class BaseClassB:
def func0(self):
this.class_a_obj = lib_class_dict['ClassB']
User code:
lib_class_dict['ClassA'] = ExtendClassA():
class ExtendClassA:
EDIT: Adding more details regarding the complexities I'm dealing with.
I have scenarios where method calls are buried deep within the library, which makes it hard to pass a class from the user entry point -> function:
(user would call BaseClassB.func0() in below example)
class BaseClassA:
class BaseClassB:
def func0(self):
this.class_c_obj = BaseClassC()
class BaseClassC:
def __init__(self):
this.class_d_obj = BaseClassD()
class BaseClassD:
def __init__(self):
this.class_a_obj = BaseClassA()
Multiple classes can create one type of object:
class BaseClassA:
class BaseClassB:
def func0(self):
this.class_a_obj = BaseClassA()
class BaseClassC:
def __init__(self):
this.class_a_obj = BaseClassA()
class BaseClassD:
def __init__(self):
this.class_a_obj = BaseClassA()
For these reasons I'm hoping to have a global or central location all classes can grab the correct class.
Allow them to specify the class to use as an optional parameter to func0
def BaseClassB:
def func0(self, objclass=BaseClassA):
self.class_a_obj = objclass()
obj1 = BlassClassB()
obj1.func0()
obj2 = BassClassB()
obj2.func0(objclass = ExtendClassA)
So, I've tried a PoC that, if I understand correctly, might do the trick. Give it a look.
By the way, whether it does work or not, I have a strong feeling this is actually a bad practice in almost all scenarios, as it changes class behavior in a obscure, unexpected way that would be very difficult to debug.
For example, in the below PoC if you inherit the same BaseClassA multiple times - only the latter inheritance shall be written in the class library, which would be a huge pain for the programmer trying to understand what on earth is happening with his code and why.
But of course, there are some use cases when shooting ourselves in a leg is less painful than designing & using a proper architecture :)
So, the first example where we have inheritance (I specified multiple inherited classes, just to show that only the last inherited one would be saved in a library):
#################################
# 1. We define all base classes
class BaseClassA:
def whoami(self):
print(type(self))
def __init_subclass__(cls):
omfg_that_feels_like_a_reeeeally_bad_practise['ClassA'] = cls
print('Class Dict Updated:')
print('New Class A: ' + str(cls))
#################################
# 2. We define a class library
global omfg_that_feels_like_a_reeeeally_bad_practise
omfg_that_feels_like_a_reeeeally_bad_practise = {}
omfg_that_feels_like_a_reeeeally_bad_practise['ClassA'] = BaseClassA
#################################
# 3. We define a first class that refer our base class (before inheriting from base class)
class UserClassA:
def __init__(self):
self.class_a_obj = omfg_that_feels_like_a_reeeeally_bad_practise['ClassA']()
#################################
# 4. We inherit from the base class several times
class FirstExtendedClassA(BaseClassA):
pass
class SecondExtendedClassA(BaseClassA):
pass
class SuperExtendedClassA(FirstExtendedClassA):
pass
#################################
# 5. We define a second class that refer our base class (after inheriting from base class)
class UserClassB:
def __init__(self):
self.class_a_obj = omfg_that_feels_like_a_reeeeally_bad_practise['ClassA']()
#################################
## 6. Now we try to refer both user classes
insane_class_test = UserClassA()
print(str(insane_class_test.class_a_obj))
### LOOK - A LAST INHERITED CHILD CLASS OBJECT IS USED!
# <__main__.SuperExtendedClassA object at 0x00000DEADBEEF>
insane_class_test = UserClassB()
print(str(insane_class_test.class_a_obj))
### LOOK - A LAST INHERITED CHILD CLASS OBJECT IS USED!
# <__main__.SuperExtendedClassA object at 0x00000DEADBEEF>
And if we remove inheritance, the base class will be used:
#################################
# 1. We define all base classes
class BaseClassA:
def whoami(self):
print(type(self))
def __init_subclass__(cls):
omfg_that_feels_like_a_reeeeally_bad_practise['ClassA'] = cls
print('Class Dict Updated:')
print('New Class A: ' + str(cls))
#################################
# 2. We define a class library
global omfg_that_feels_like_a_reeeeally_bad_practise
omfg_that_feels_like_a_reeeeally_bad_practise = {}
omfg_that_feels_like_a_reeeeally_bad_practise['ClassA'] = BaseClassA
#################################
# 3. We define a first class that refer our base class
class UserClassA:
def __init__(self):
self.class_a_obj = omfg_that_feels_like_a_reeeeally_bad_practise['ClassA']()
#################################
# 5. We define a second class that refer our base class
class UserClassB:
def __init__(self):
self.class_a_obj = omfg_that_feels_like_a_reeeeally_bad_practise['ClassA']()
#################################
## 6. Now we try to refer both user classes
insane_class_test = UserClassA()
print(str(insane_class_test.class_a_obj))
### LOOK - A DEFAULT CLASS OBJECT IS USED!
# <__main__.BaseClassA object at 0x00000DEADBEEF>
insane_class_test = UserClassB()
print(str(insane_class_test.class_a_obj))
### LOOK - A DEFAULT CLASS OBJECT IS USED!
# <__main__.BaseClassA object at 0x00000DEADBEEF>

Python3 generic inheritance hierarchy

This question is specific for python 3. Suppose I have a class hierarchy like this
class Base():
def calculate():
return 0
class Derived1(Base):
def calculate():
# some calculation
class Derived2(Base):
def calculate():
# some calculation
Now, what I want to do is make a class that defines a generic way to inherit from the Derived classes, and then overrides calculate. In other words, something in the spirit of C++ templates, to avoid copying over the subclasses code, but specify a generic way of subclassing, and then be able to define the subclasses as one liners, like shown below:
# pseudocode
class GenericDerived5(someGenericBase):
def calculate():
return super().calculate() + 5
class GenericDerived6(someGenericBase):
def calculate():
return super().calculate() + 5
class Derived5_1 = GenericDerived5(Derived1)
class Derived6_1 = GenericDerived6(Derived2)
(the calculation is not literally like this, just illustrating the combinatorial nature of the inheritance structure)
How would this code look like, and what are the relevant tools from python3 that I need? I've heard of metaclasses, but not very familiar.
class definition inside a factory-function body
The most straightforward way to go there is really straightforward - but can feel a bit awkward:
def derived_5_factory(Base):
class GenericDerived5(Base):
def calculate(self):
return super().calculate() + 5
return GenericDerived5
def derived_6_factory(Base):
class GenericDerived6(Base):
def calculate(self):
return super().calculate() + 6
return GenericDerived6
Derived5_1 = derived_5_factory(Derived1)
Derived6_2 = derived_6_factory(Derived2)
The inconvenient part is that your classes that need generic bases
have to be defined inside function bodies. That way, Python re-executes
the class statement itself, with a different Base, taking advantage
that in Python classes are first class objects.
This code have the inconveniences that (1) the class bodies must be inside functions, and (2) it can be the wrong approach at all:
Multiple inheritance
If you can have an extra inheritance level - that is the only difference for your example, this is the "correct" way to go. Actually, apart from having the former "GenericDerived" classes explicitly in their inheritance chain, they will behave exactly as intended:
class Base():
def calculate():
return 0
class Derived1(Base):
def calculate(self):
return 1
class Derived2(Base):
def calculate(self):
return 2
# mix-in bases:
class MixinDerived5(Base):
def calculate(self):
return super().calculate() + 5
class MixinDerived6(Base):
def calculate(self):
return super().calculate() + 6
Derived5_1 = type("Derived5_1", (MixinDerived5, Derived1), {})
Derived6_2 = type("Derived6_2", (MixinDerived6, Derived2), {})
Here, instead of using the class statement, a dynamic class is created with the type call, using both the class that needs a dybamic base and that dynamic base as its bases parameter. That is it - Derived5_1 is a fully working Python class with both Bases in its inheritance chain
Note that Python's super() will do exactly what common sense would expect it to do, "rerouting" itself through the extra intermediary "derived" classes before reaching "Base". So, this is what I get on the interactive console after pasting the code above:
In [6]: Derived5_1().calculate()
Out[6]: 6
In [7]: Derived6_2().calculate()
Out[7]: 8
A mix-in class, roughly speaking, is a class that isn't intended to be instantiated directly or act as a standalone base class (other than for other, more specialized mix-in classes), but to provide a small subset of functionality that another class can inherit.
In this case, your GenericDerived classes are perfect examples of mix-ins: you aren't creating instances of GenericDerived, but you can inherit from them to add a calculate method to your own class.
class Calculator:
def calculate(self):
return 9
class Calculator1(Calculator):
def calculate(self):
return super().calculate() + 5
class Calculator2(Calculator):
def calculate(self):
return super().calculate() + 10
class Base(Calculator):
...
Note that the Base and Calculator hierarchies are independent of each other. Base provides, in addition to whatever else it does, basic calculate functionality. A subclass of Base can use calculate that it inherits from Base (via Calculator), or it can inherit from a subclass of Calculator as well.
class Derived1(Base):
...
class Derived2(Base, Calculator1):
...
class Derived3(Base, Calculator2):
...

Can we call a method from within a class of no instantiation

I would like to ask if there is a way to implement an interface method within a class without instantiation, or even more, if it is altogether a bad practice? If so, what will be the right way to implement a complex interface method?
Here is a prototype of my code:
class calculator(abc.ABC):
#abc.abstractmethod
def calculate(self):
"start model"
class subcalculator(calculator):
def calculate(self):
return model.attr2 ** 3
def recalculate(self):
z = calculate(self)
return z ** 2
However, this reports calculate() is not defined when run subcalculator.recalculate as it is not instantiated.
As I am just writing interface classes for my model, I suppose writing initiation is not a good idea.(Or is it?) What should I do then in such case?
Edit: According to #chepner 's answer, I have also figured out some hackish way to solve this problem, which I am not sure if it's right practice:
#classmethod
def recalculate(cls, self):
z = cls.calculate(self)
return z ** 2
Also it's worth mentioning the object/model part of the structure:
#In model.py
class model(object):
def __init__(self, attr1):
self.attr1 = attr1
class submodel(model):
def __init__(self, attr1, attr2):
super().__init__(attr1)
self.attr2 = attr2
So my hope is to write calculator as an interface class which can interact with model etc.
calculate is a method whether or not you ever create an instance, and has to be referred to as such.
class subcalculator(calculator):
def calculate(self):
return model.attr2 ** 3
def recalculate(self):
z = subcalculator.calculate(self)
return z ** 2
Of course, it's better to let the inheritance model determine exactly which calculate method needs to be called:
def recalculate(self):
z = self.calculate()
return z ** 2

Python - Inheritance

I'm not understanding any online documentation about how to make inheritance work.
I have this here:
import maya.cmds as cmds
class RigLegs():
def __init__(self, *args):
self.rigLegs()
def rigLegs(self):
self.items["side"] = "left"
self.lIK = cmds.duplicate(self.lJoints["hip"], n = self.getName("hip_IK"))
for i in self.lIK:
newName = i[0].replace("_JNT", "_IK")
cmds.rename(i, newName)
But it's complaining that there is no self.items - I have to inherit it from another class which is far too large to post here. Can anyone help me figure out how to do that? I've researched online and nothing makes any sense.
The other class is in a different file altogether.
To inherit from another class do:
class RigLegs(base_class_name):
An Example:
class base_class():
items = [1,2,3]
class pie(base_class):
def __init__(self):
print (self.items)
instance = pie()
You can read more in the Python Documentation
With imports:
file (apples.py)
class base():
items = [1,3,4]
file (main_file.py)
import apples
class pie(apples.base):
def __init__(self):
self.pies()
def pies(self):
print(self.items)
instance = pie()
In the class declaration: class RigLegs(), you should include all the classes you want to inherit from, such as in:
class RigLegs(Ancestor1, Ancestor2):
# Your code chere.
Don't forget that you still need to call the initialization logic of your ancestors.
def __init__(self):
super(RigLegs, self).__init__()

Categories