Factory method signature for aggregate root

Question

I want to write a factory method to instantiate an entity that is an aggregate root.

Should the method accept the aggregated child entities and values as instantiated objects, or should it accept only primitive types?

For example, if I had an entity Computer composed of a Processor and a Memory object, should the factory method take the form:

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

or

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

Is it only a matter of taste, or are there any serious considerations here?

Answer 1

It's just a matter of taste, though it can depend on your object-creation strategy, plus you might mix and match them.

Where your aggregate root already has factory methods for its child objects (e.g., if CreateProcessor() already exists to support adding additional processors), your first approach might be appropriate.

Alternately, if you're using a ComputerFactory (or repository) to create or reconstitute your aggregate root, that factory may already knows how to create child objects, in which case it will create them en route to building up your aggregate's graph and your second approach will be appropriate.

Answer 2

An 'aggregate root' is the topmost node of an object graph. All other objects are created and accessed via this root object. In other words: If you create the components of the Computer class by an external factory method, then you cannot call it 'aggregate root' any more. This is not to say that your second example is somehow bad or smelly or something, it's just that it doesn't meet the 'aggregate root' concept...

Answer 3

Regarding to the benefits of using the Factory Method (I am not very familiar with the rules of Aggregates and Roots):

• I imagine Processor and Memory are objects having certain behaviors that you want to separate from your Computer Class.

• The computer class constructor could be

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

Your Computer class now does not depend on specific implementation of Processor and Memory. Other class is responsible on using a computer with specific Memory and Processor.

With this approach you will have benefits of having more maintainable code, and being able to upgrade the Memory and Processor without changing the Computer.

Dont know if this answear your question in your particular scenario, but Hope this helps. Other resources are:

1. http://www.objectmentor.com/resources/articles/inheritanceVsDelegation.pdf
2. SOLID ebook: http://www.lostechies.com/content/pablo%5Febook.aspx