Подпись фабричного метода для совокупного корня - PullRequest
Новая
       4

Подпись фабричного метода для совокупного корня

3 голосов
/ 06 октября 2009

Я хочу написать фабричный метод для создания экземпляра сущности, являющейся совокупным корнем.

Должен ли метод принимать агрегированные дочерние объекты и значения как созданные объекты или он должен принимать только примитивные типы?

Например, если бы у меня был сущностный компьютер, состоящий из процессора и объекта памяти, фабричный метод должен принять форму: 

public Computer NewComputer(
    string computerName, 
    int processorCores, 
    int processorClockSpeed, 
    string memoryType, 
    int memoryRam) 
{
    ...
}

или 

public Computer NewComputer(
    string computerName, 
    Processor processor, 
    Memory memory) 
{
    ...
}

Это только вопрос вкуса или здесь есть какие-то серьезные соображения?

Ответы [ 3 ]

2 голосов
/ 06 октября 2009

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

Если в вашем агрегированном корне уже есть фабричные методы для его дочерних объектов (например, если CreateProcessor() уже существует для поддержки добавления дополнительных процессоров), ваш первый подход может быть уместным.

С другой стороны, если вы используете ComputerFactory (или хранилище) для создания или воссоздания вашего сводного корня, эта фабрика может уже знать, как создавать дочерние объекты, и в этом случае она будет создавать их на пути к созданию График агрегата и ваш второй подход будут уместны.

1 голос
/ 06 октября 2009

Относительно преимуществ использования фабричного метода (я не очень знаком с правилами агрегатов и корней):

  • Я полагаю, что Процессор и Память - это объекты, имеющие определенное поведение, которое вы хотите отделить от своего Класса Компьютера.

  • Конструктор класса компьютера может быть 

    public Computer(string computerName, IProcessor processor, IMemory memory) 
{
}

Класс вашего компьютера теперь не зависит от конкретной реализации процессора и памяти. Другой класс отвечает за использование компьютера с определенной памятью и процессором.

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

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

  1. http://www.objectmentor.com/resources/articles/inheritanceVsDelegation.pdf
  2. Электронная книга SOLID: http://www.lostechies.com/content/pablo_ebook.aspx
1 голос
/ 06 октября 2009

Совокупный корень - это самый верхний узел графа объектов. Все остальные объекты создаются и доступны через этот корневой объект. Другими словами: если вы создаете компоненты класса Computer с помощью внешнего метода фабрики, вы больше не можете называть его «агрегатным корнем». Это не значит, что ваш второй пример плохой или вонючий или что-то в этом роде, просто он не соответствует концепции «совокупного корня» ...

...