gmane.comp.programming.domain-driven-design

moffdub | 6 Aug 23:13

Factory Method Pattern via Inner Classes

When it comes to Factories in DDD, most of the time, I am in the
situation to apply the Factory Method Pattern and not some of the
generalization-heavy patterns like Abstract Factory or Builder.

If I have a well-designed and encapsulated domain object for which I
want to provide a factory, usually there will be parts of the
construction that are simple, like directly initializing integers and
strings, and then other parts that are complicated -- the parts that
motivated me to create a factory in the first place.

Suppose I am in Java, so there are no "friend" modifiers or partial
classes. Since my domain object is well-encapsulated, I don't have
setters for each and every simple string or integer. They are
initialized through the constructor and changed only through other
non-setter methods that have domain meaning and encapsulate logic. If
I try to move this stuff from the constructor to a factory class, it
breaks because those simple strings and integers are private and not
accessible. The privatization of the domain object's constructor poses
a similar problem.

What are your thoughts on making the factory class a static member
class in order to have access to the privates:

public class Order
{
        ...
        ...
        ...

        /* **** factory class **** */

(Continue reading)

headers

Michael Hunger | 6 Aug 23:44

Re: Factory Method Pattern via Inner Classes

I could also imagine using an factory method on the Order itself
-> Order.createOrder()
which then either:
* does the creation itself
* delegates to a static factory like your example
* delegates to an factory instance held in an instance variable (possibly setable by Dependency Injection)

It depends on the complexity of the setup which approach you choose to start with.

I don't think this pollutes the Order to much because the creation of itself unproblematic in the sense of SRP.

Another question is why you need access to internal fields in the factory and not just setting them in the
constructor 
(or on the other hand in a public factory method of the order itself)?

Michael

--

-- 
Michael Hunger
Independent Consultant

Web: http://www.jexp.de
Email: michael.hunger <at> jexp.de

Enthusiastic Evangelist for Better Software Development

Don't stop where you are: http://creating.passionate-developers.org
We support Software Engineering Radio (www.se-radio.net)

------------------------------------

(Continue reading)

headers

moffdub | 7 Aug 00:07

Re: Factory Method Pattern via Inner Classes

Thanks for the reply. Wouldn't delegating to a factory held in an
instance variable cut you off from accessing private members?

Assuming you are talking about a top-level class, the problem with the
factory using a constructor is I've made the constructor of Order
private to force users of Order to use the factory.

Doing Order.createOrder() works, but it seems contrary to the spirit
of separating the construction of the object from the object itself.
I'm aware that my static inner class solution is essentially
equivalent, save for clearer syntax for the caller. 

I think Order.OrderFactory.createOrder(), imperfect as it is, makes it
clear what is going on to someone cognizant of patterns.
Order.createOrder() is a little less clear to me.

--- In domaindrivendesign <at> yahoogroups.com, Michael Hunger <ddd@...> wrote:
>
> I could also imagine using an factory method on the Order itself
> -> Order.createOrder()
> which then either:
> * does the creation itself
> * delegates to a static factory like your example
> * delegates to an factory instance held in an instance variable
(possibly setable by Dependency Injection)
> 
> It depends on the complexity of the setup which approach you choose
to start with.
> 
> I don't think this pollutes the Order to much because the creation

(Continue reading)