settattr для родительского класса для использования у детей

Question

у меня есть библиотека с одним из родителей и дюжина детей:

# mylib1.py: 
# 
class Foo(object): 
    def __init__(self, a): 
    self.a = a 


class FooChild(Foo): 
    def __init__(self, a, b): 
    super(FooChild, self).__init__(a) 
    self.b = b 

# more children here... 

Теперь я хочу расширить эту библиотеку с простым (но немного spesific, для использования в другой подход). Поэтому я хотел бы изменить родительский класс и использовать его дочерние элементы.

# mylib2.py: 
# 
import mylib1 

def fooMethod(self): 
    print 'a={}, b={}'.format(self.a, self.b) 

setattr(mylib1.Foo, 'fooMethod', fooMethod) 

И теперь я могу использовать его как это:

# way ONE: 
import mylib2 

fc = mylib2.mylib1.FooChild(3, 4) 
fc.fooMethod() 

или как это:

# way TWO: 
# order doesn't matter here: 
import mylib1 
import mylib2 

fc = mylib1.FooChild(3, 4) 

fc.fooMethod() 

Итак, мои вопросы:

1. Это хорошая вещь ?
2. Как это должно быть сделано лучше?

Answer 1

Общий подход заключается в использовании mixin

Если вы хотите, вы можете добавить динамически How do I dynamically add mixins as base classes without getting MRO errors?.

Answer 2

В программировании существует общее правило, что вы должны избегать зависимости от глобального состояния. Это означает, что ваши глобальные переменные должны быть по возможности постоянными. Классы (в основном) - глобальные.

Ваш подход называется патчем обезьяны. И если у вас нет по-настоящему веской причины объяснять это, вы должны избегать этого. Это связано с тем, что исправление обезьяны нарушает вышеуказанное правило.

Представьте, что у вас есть два отдельных модуля, и оба они используют этот подход. Один из них устанавливает Foo.fooMethod для некоторого метода. Другое - другому. Затем вы каким-то образом переключаете управление между этими модулями. В результате было бы трудно определить, где именно используется fooMethod. Это означает, что трудно отлаживать проблемы.

Есть люди (например, Брэндон Крейг-Родос), которые считают, что исправление плохо даже в тестах.

Что я хотел бы предложить, это использовать некоторые атрибуты, которые вы задали бы при создании экземпляров вашего класса Foo() (и его дочерних элементов), которые будут контролировать поведение вашего fooMethod. Тогда поведение этого метода будет зависеть от того, как вы создавали экземпляр объекта, а не из глобального состояния.