Как структурировать методы классов, которые наследуются от одного BaseClass?

Question

У меня много разных дочерних классов, которые наследуются от одного базового класса.Однако все разные дочерние классы реализуют очень похожие методы.Поэтому, если я хочу изменить код в дочерних классах, я должен изменить его несколько раз.

Для меня это звучит как плохая практика, и я хотел бы реализовать его правильно.Но после долгих поисков я так и не нашел последовательного способа, как это должно быть сделано.

Вот пример того, что я имею в виду:

from ABC import ABC, abstractmethod
import logging.config

class BaseModel(ABC):
    def __init__(self):
        # initialize logging
        logging.config.fileConfig(os.path.join(os.getcwd(),
            '../myconfig.ini'))
        self.logger = logging.getLogger(__name__)

    @abstractmethod
    def prepare_data(self):
        """
        Prepares the needed data.
        """
        self.logger.info('Data preparation started.\n')
        pass

Так что это мойBaseClass.Теперь из этого класса несколько других классов наследуют метод init и prepare_data.Метод prepare_data очень похож для каждого класса.

class Class_One(BaseModel):
    def __init__(self):
        super.__init()__

    def prepare_data(self):
        super().prepare_data()
        # Some code that this method does


class Class_Two(BaseModel):
    def __init__(self):
        super.__init()__

    def prepare_data(self):
        super().prepare_data()
        # Some code that this method does
        # Code is almost the same as for Class_One


class Class_Three(BaseModel):
    def __init__(self):
        super.__init()__

    def prepare_data(self):
        super().prepare_data()
        # Some code that this method does
        # Code is almost the same as for Class_One and Class_Two

# etc.

Полагаю, вы могли бы реорганизовать методы в другой файл и затем вызывать их в каждом классе.Я хотел бы знать, как сделать это правильно.Заранее большое спасибо!

Answer 1

Боюсь, что нет универсального универсального магического ответа - все это действительно зависит от «почти» части И от сил, которые будут стимулировать изменения в этих частях кода.Итак, на самом деле можно ответить только на конкретном примере ...

Как говорится, есть несколько уроков, извлеченных из опыта, которые в основном суммированы в известной (но, к сожалению, часто неправильно понятой) GOFКнига «Узоры дизайна» .Если вы потратите время на first чтение части first книги, вы поймете, что большинство (если не все) шаблонов в каталоге основаны на том же принципе: отделить вариант от инварианта .Как только вы можете отличить одно от другого в своем коде (предупреждение: здесь есть ловушка, и новичок почти всегда попадает в нее), какой шаблон для применения обычно очевиден (иногда до такой степени, что вы понимаете, что использовали только этот и тот шаблоны после вы реорганизовали свой код).

Теперь, как я уже сказал, есть ловушка: случайное дублирование.Тот факт, что два фрагмента кода выглядят похожими, не означает, что они являются дубликатами - довольно часто они только "случайно" похожи сейчас , но силы, которые будут вносить одно или другое изменениев основном не связаны.Если вы попытаетесь немедленно провести рефакторинг этого кода, вы вскоре обнаружите, что делаете «универсальный» случай все более и более сложным, чтобы поддержать изменения, которые на самом деле не связаны, и в итоге вы получите чрезмерно усложненный неразборчивый беспорядок, который только делает ваш код неуправляемым.Таким образом, хитрость здесь заключается в том, чтобы тщательно изучить весь контекст, спросить себя, что могло бы привести к изменениям в одной или других «похожих» частях, и, если сомневаетесь, подождать, пока вы не узнаете больше.Если это произойдет, чем каждый раз, когда вы меняете A, вы должны вносить одно и то же изменение в B по тем же причинам, тогда у вас действительно есть дубликат.

Для более практического, краткосрочного совета, основанного на том, что мыИсходя из вашего слишком абстрактного примера (и из собственного опыта), можно предположить, что существует как минимум два шаблона, которые чаще всего участвуют в устранении дублирования в иерархии классов: метод шаблона и стратегия.

NB: я сказал «к сожалению, часто неправильно понимают», потому что большинство людей, кажется, прыгают в каталог шаблонов и пытаются принудительно вписать их все в свой код (имеет ли это смысл для рассматриваемой проблемы или нет)) и обычно путем копирования-вставки канонического учебника _implementation_ (обычно на основе Java или C ++) вместо понимания _concept_ и его реализации таким образом, который одновременно идиоматичен и адаптирован к конкретному случаю использования (пример: когда функции являются объектом первого класса,вам не обязательно нужен Strategie класс с абстрактным основанием и конкретными подклассами - чаще всего это простые старые функции обратного вызова JustWork (tm)).