плюсы и минусы использования factory vs regular constructor

(используя Python 3.2, хотя я сомневаюсь, что это имеет значение.)

я class Data, class Rules, и класс Result. Я использую нижний регистр для обозначения экземпляра класса.

A rules объект содержит правила, которые, если применить к

9
architecture class-factory design-patterns oop python

5 ответов

на принципы дизайна схватки укажите рекомендации по назначению ответственности классам и объектам в объектно-ориентированном дизайне. Например,создатель шаблон предполагает: в общем случае класс B должен отвечать за создание экземпляров класса A, если применяется один или, предпочтительно, несколько из следующих:

  • экземпляры B содержит или композитно агрегирует экземпляры a
  • экземпляры экземпляров записи B А
  • экземпляры B тесно используют экземпляры a
  • экземпляры B имеют инициализирующую информацию для экземпляров A и передают ее при создании.

в вашем примере у вас есть сложный и развивающийся код для применения правил к данным. Это предполагает использование Шаблон Фабрики.

ввод кода результаты противопоказано, потому что 1) результаты не создать результаты, и 2) результаты не эксперт по информации (т. е. у них нет большей части необходимых знаний).

короче,ResultFactory кажется разумным местом для концентрации знаний о том, как применять правила до данные для создания результаты. Если вы попытаетесь протолкнуть всю эту логику в конструкторы классов для получения результатов или правил, это приведет к жесткой связи и потере сцепления.

4

третий сценарий:

вы можете рассмотреть третий вариант:

  • поместите код внутри метода Rules.__call__.
    Инстанцирование Result как: result = rules(data)

плюсы:

  • Results может быть полностью не осведомлен о Rules это генерирует их (и, возможно, даже из оригинала Data).
    • Rules подкласс может настроить его Result создание.
  • это кажется естественным (для меня):Rules применил к Data доходность Result.
  • и у вас будет пара принципов захвата на вашей стороне:
    • создатель: экземпляры Rules имейте инициализирующую информацию для экземпляров Result и передать его на создание.
    • Эксперт По Информации: эксперт по информации приведет к возложению ответственности на класс с наибольшей информацией, необходимой для выполнить его.

побочные эффекты:

  • соединение: вы поднимете соединение между Rules и Data:
    • вам нужно пройти весь набор данных для каждого Rules
    • что означает, что каждый Rules должен быть в состоянии решить, на какие данные он будет применяться.
2

Почему бы не поместить правила в свои собственные классы? Если вы создаете класс базы правил, то каждое правило может быть производным от него. Таким образом, полиморфизм может использоваться, когда данные требуют применения правил. Данные не должны знать или заботиться о том, какие экземпляры правил были применены (если только сами данные не знают, какие правила должны применяться).

когда правила должны быть вызваны, экземпляр данных может все базы правил.ExecuteRules () и передать себя в качестве аргумента. Правильный подкласс Rule может быть выбирается непосредственно из данных, если данные знают, какое правило необходимо. Или можно использовать какой-то другой шаблон проектирования, например цепочку ответственности, где данные вызывают шаблон и позволяют результату вернуться.

Это было бы отличное обсуждение доски.

1

можете ли вы сделать ResultFactory чистой функцией? Не полезно создавать одноэлементный объект, если все, что вам нужно, это функция.

1

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

0