[OT] Non-abstract factory design pattern versus using constructordirectory

[marlow.andrew]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

I am not sure why some people advocate using the factory design
pattern to create instances of objects where the constructor could be
used just as easily (IMHO). I am aware of the Abstract Factory design
pattern (AFDP) in the GoF and I do agree that AFDP has its uses. But
what is being advocated (not by me) in this case is a non-abstract
factory.

Recently I have been working in an agile envirornment and on two
separate occasions my pair partner (a different person each time)
stopped me from creating an object via its constructor and got me to
use the non-abstract factory design pattern to create the object. The
classes in question were concrete and there were no associated
interfaces. I don't see what this buys you. I would have simply uses
the concrete classes constructor. I agreed to do it this way because
there may be some benefit that I don't know about. We didn't have time
to argue about it. So I did it using a factory and thought I would
raise the question here to find out what I am missing about this.

At no time are interfaces being used and the factory still needs to be
supplied with all the data that I would have passed via the
constructor. Every time one of these objects has to be created the
factory is used so instead of calls to the constructor being sprinkled
throughout the code, calls to the factory create method with the same
arguments as the classes constructor are sprinkled throughout the
code. So if the constructor argument list changed I would have to
change its invocation in only one place, the factory, but I would also
have to change all the places where the factory create method was
invoked since this would change too.

Regards,

Andrew Marlow

 

[Joshua Cranmer]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

comp.theory is probably a good place (I am not a denizen of said
newsgroup, so I can't say for sure).

I am not sure why some people advocate using the factory design
pattern to create instances of objects where the constructor could be
used just as easily (IMHO). I am aware of the Abstract Factory design
pattern (AFDP) in the GoF and I do agree that AFDP has its uses. But
what is being advocated (not by me) in this case is a non-abstract
factory.

A minor point, but factories are probably more future-proof. If you
decide that a class would be, in the future, better designed as a light
hierarchy based on some of the inputs via a factory method, you can make
that change without breaking compatibility. If you have a constructor,
you're stuck with it. This point, though, does need to be evaluated on a
case-by-case basis.

Factories are also flexible in the creation of objects. Suppose you
decide at some point that you need (for performance reasons) to have
interned representations of objects. A constructor has to create a new
object, but a factory can choose to reuse an existing item.

Those two are the first reasons that come to my mind; there are other
reasons, though (probably).

 

[John B. Matthews]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

I am not sure why some people advocate using the factory design
pattern to create instances of objects where the constructor could be
used just as easily (IMHO). I am aware of the Abstract Factory design
pattern (AFDP) in the GoF and I do agree that AFDP has its uses. But
what is being advocated (not by me) in this case is a non-abstract
factory.

Recently I have been working in an agile envirornment and on two
separate occasions my pair partner (a different person each time)
stopped me from creating an object via its constructor and got me to
use the non-abstract factory design pattern to create the object. The
classes in question were concrete and there were no associated
interfaces. I don't see what this buys you. I would have simply uses
the concrete classes constructor. I agreed to do it this way because
there may be some benefit that I don't know about. We didn't have time
to argue about it. So I did it using a factory and thought I would
raise the question here to find out what I am missing about this.

At no time are interfaces being used and the factory still needs to be
supplied with all the data that I would have passed via the
constructor. Every time one of these objects has to be created the
factory is used so instead of calls to the constructor being sprinkled
throughout the code, calls to the factory create method with the same
arguments as the classes constructor are sprinkled throughout the
code. So if the constructor argument list changed I would have to
change its invocation in only one place, the factory, but I would also
have to change all the places where the factory create method was
invoked since this would change too.

In _Effective_Java_, Joshua Bloch advises, "Consider static factory
methods." He goes on to enumerate several pros and cons of the approach,
which one should consider before deciding:

<http://www.ddj.com/java/208403883>

Could your colleagues adduce any specific reason(s) for their choice?

 

[Mike Schilling]

A minor point, but factories are probably more future-proof. If you
decide that a class would be, in the future, better designed as a
light hierarchy based on some of the inputs via a factory method, you
can make that change without breaking compatibility. If you have a
constructor, you're stuck with it. This point, though, does need to
be evaluated on a case-by-case basis.

Factories are also flexible in the creation of objects. Suppose you
decide at some point that you need (for performance reasons) to have
interned representations of objects. A constructor has to create a new
object, but a factory can choose to reuse an existing item.

Good points, but in neither case are you completely "stuck": you can make
the created object a thin cover over the hierarchy or interned
representation. In the latter case, it won't be as efficient as returning
the interned object directly, but it should be close enough unless you're
creating millions of them.

 

[Arne Vajhøj]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

I am not sure why some people advocate using the factory design
pattern to create instances of objects where the constructor could be
used just as easily (IMHO). I am aware of the Abstract Factory design
pattern (AFDP) in the GoF and I do agree that AFDP has its uses. But
what is being advocated (not by me) in this case is a non-abstract
factory.

Recently I have been working in an agile envirornment and on two
separate occasions my pair partner (a different person each time)
stopped me from creating an object via its constructor and got me to
use the non-abstract factory design pattern to create the object. The
classes in question were concrete and there were no associated
interfaces. I don't see what this buys you. I would have simply uses
the concrete classes constructor. I agreed to do it this way because
there may be some benefit that I don't know about. We didn't have time
to argue about it. So I did it using a factory and thought I would
raise the question here to find out what I am missing about this.

At no time are interfaces being used and the factory still needs to be
supplied with all the data that I would have passed via the
constructor. Every time one of these objects has to be created the
factory is used so instead of calls to the constructor being sprinkled
throughout the code, calls to the factory create method with the same
arguments as the classes constructor are sprinkled throughout the
code. So if the constructor argument list changed I would have to
change its invocation in only one place, the factory, but I would also
have to change all the places where the factory create method was
invoked since this would change too.

Using a factory is good if the type in question is a type
that somehow contains implementation choices.

You will obviously first see the benefits the day the
class is subclassed, but even if it is not today then it
may be in 1 year or 5 years.

You should not use it for all types. Creating a factory method
to create Integer objects would be rather pointless.

Instead of creating your own factory classes, then you
could look at Spring.

Arne

 

[Arved Sandstrom]

(e-mail address removed) wrote:
[ SNIP ]

Recently I have been working in an agile envirornment and on two
separate occasions my pair partner (a different person each time)
stopped me from creating an object via its constructor and got me to
use the non-abstract factory design pattern to create the object. The
classes in question were concrete and there were no associated
interfaces. I don't see what this buys you. I would have simply uses
the concrete classes constructor. I agreed to do it this way because
there may be some benefit that I don't know about. We didn't have time
to argue about it. So I did it using a factory and thought I would
raise the question here to find out what I am missing about this.

At no time are interfaces being used and the factory still needs to be
supplied with all the data that I would have passed via the
constructor. Every time one of these objects has to be created the
factory is used so instead of calls to the constructor being sprinkled
throughout the code, calls to the factory create method with the same
arguments as the classes constructor are sprinkled throughout the
code. So if the constructor argument list changed I would have to
change its invocation in only one place, the factory, but I would also
have to change all the places where the factory create method was
invoked since this would change too.

In _Effective_Java_, Joshua Bloch advises, "Consider static factory
methods." He goes on to enumerate several pros and cons of the approach,
which one should consider before deciding:

<http://www.ddj.com/java/208403883>

Could your colleagues adduce any specific reason(s) for their choice?

Bloch's article is a good one (although I thought it was a bit ironic that
the names he chose for his static factory methods, which is what people tend
to name these things, deviates rather substantially from his first point
about the advantages of such methods) . From the OP's description, I
wouldn't be surprised if his colleagues were satisfied with something like

FurbitzFactory.newInstance(String name, double weight, int age);

where newInstance(...) does absolutely nothing but call the Furbitz
constructor with the same parameters.

If I were the OP, I would definitely ask my peers why they recommended
(required) a factory method pattern. Not only that, I'd ask them what the
disadvantages of it were. Not that I'm looking to raise hell, but I do
dislike people that recommend something without knowing why.

AHS

 

[Joshua Cranmer]

Good points, but in neither case are you completely "stuck": you can make
the created object a thin cover over the hierarchy or interned
representation. In the latter case, it won't be as efficient as returning
the interned object directly, but it should be close enough unless you're
creating millions of them.

Obviously, this is a case-by-case decision. The link Mr. Matthews
provided does a better job explaining than I did (I forgot about the
ability to infer generic types, even though I once wrote a factory-like
method (for a CS HW assignment) to do just that...).

But note how Mr. Bloch titled the item: "Consider..." instead of (say)
"Prefer..." Factories are not panaceas, but they are a choice. In the
OP's case, they're probably being foisted on him in a blind "urr,
factories-are-GOD!" belief.

Even though one can always add factory methods later, that's not an
excuse for obviously bad constructors (like the BigInteger constructor
that makes a probably-prime integer...). One can also add in public
constructors later and keep binary compatibility.

 

[marlow.andrew]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

I am not sure why some people advocate using the factory design
pattern to create instances of objects where the constructor could be
used just as easily (IMHO). I am aware of the Abstract Factory design
pattern (AFDP) in the GoF and I do agree that AFDP has its uses. But
what is being advocated (not by me) in this case is a non-abstract
factory.

Recently I have been working in an agile envirornment and on two
separate occasions my pair partner (a different person each time)
stopped me from creating an object via its constructor and got me to
use the non-abstract factory design pattern to create the object. The
classes in question were concrete and there were no associated
interfaces. I don't see what this buys you. I would have simply uses
the concrete classes constructor. I agreed to do it this way because
there may be some benefit that I don't know about. We didn't have time
to argue about it. So I did it using a factory and thought I would
raise the question here to find out what I am missing about this.

At no time are interfaces being used and the factory still needs to be
supplied with all the data that I would have passed via the
constructor. Every time one of these objects has to be created the
factory is used so instead of calls to the constructor being sprinkled
throughout the code, calls to the factory create method with the same
arguments as the classes constructor are sprinkled throughout the
code. So if the constructor argument list changed I would have to
change its invocation in only one place, the factory, but I would also
have to change all the places where the factory create method was
invoked since this would change too.

Using a factory is good if the type in question is a type
that somehow contains implementation choices.

Indeed, just as the GoF have it in their description of AFDP.

You will obviously first see the benefits the day the
class is subclassed, but even if it is not today then it
may be in 1 year or 5 years.

But that is not the case here.

You should not use it for all types.

Well, that was my misgiving....

 

[marlow.andrew]

No. They would say they don't have the time and that I should read
GoF.

FurbitzFactory.newInstance(String name, double weight, int age);

where newInstance(...) does absolutely nothing but call the Furbitz
constructor with the same parameters.

That's not what they have. They have a factory that has private data
members for all those ctor args, and setter methods for each of them,
and a build method that invokes the ctor with the values of the
private members. Here is what the factory invocation would look like:

Frubitz furbitz = new FurbitzFactory().withName(name).withWeight
(weight).withAge(age).build();

The ctor of the factory initialises all the private data members with
default values. If any of the 'with' methods are not called then
'build' will use the default value.

One of the reasons they say this is better is that you can see from
the setter names what the parameters are. I prefer to make the meaning
of parameter clear by giving them clear descriptive short names.
Another reason they say is that you can employ default values for any
ctor arg you don't want. In that case I would have to decide whether
or not it makes sense for objects of that class to allow construction
in that way. If it does then I would overload the constructor.

Regards,

Andrew Marlow

 

[marlow.andrew]

(e-mail address removed) wrote:
A minor point, but factories are probably more future-proof. If you
decide that a class would be, in the future, better designed as a light
hierarchy based on some of the inputs via a factory method, you can make
that change without breaking compatibility.

The class being created is a simple concrete class with no interface
and no hierarchy. IMO it does not make sense for such objects to be
created with default values, all ctor args are needed always. As and
when the ctor arg list ever gets extended a factory-based approach
would have to deal with this issue too. This would involve visiting
each bit of code that used the factory to ensure the extra parameters
were supplied.

Factories are also flexible in the creation of objects. Suppose you
decide at some point that you need (for performance reasons) to have
interned representations of objects. A constructor has to create a new
object, but a factory can choose to reuse an existing item.

Yes, I think that object pooling is a valid example. Good point.
Although this can be managed internally I think it is clearer when a
factory is used. Usually the fact that a pool is employed features in
the documentation though and is one of the prime concerns. That is not
the case in the situation I am in.

Those two are the first reasons that come to my mind; there are other
reasons, though (probably).

I hope to hear about them in this thread. So far object pooling is the
most convincing argument I have seen.

-Andrew Marlow

 

[John B. Matthews]

No. They would say they don't have the time and that I should read
GoF.

Sadly, this sounds like they believe themselves "too busy to write
comments."

That's not what they have. They have a factory that has private data
members for all those ctor args, and setter methods for each of them,
and a build method that invokes the ctor with the values of the
private members. Here is what the factory invocation would look like:

Frubitz furbitz = new FurbitzFactory().withName(name).withWeight
(weight).withAge(age).build();

The ctor of the factory initialises all the private data members with
default values. If any of the 'with' methods are not called then
'build' will use the default value.

Bloch goes on to discuss the builder pattern in item 2:

One of the reasons they say this is better is that you can see from
the setter names what the parameters are. I prefer to make the meaning
of parameter clear by giving them clear descriptive short names.
Another reason they say is that you can employ default values for any
ctor arg you don't want. In that case I would have to decide whether
or not it makes sense for objects of that class to allow construction
in that way. If it does then I would overload the constructor.

I would consider it sufficient to comment the choice, either way. E.g
"Having many parameters with invariants, objects of this class are
constructed using a builder pattern."

 

[Tom Anderson]

No. They would say they don't have the time and that I should read GoF.

Hmm. Ask them again at lunch. This sounds a lot to me like "i read that
factories are a good idea, and i'm too stupid to actually think about it,
so i'm going to use them and refuse to explain my decision".

That's not what they have. They have a factory that has private data
members for all those ctor args, and setter methods for each of them,
and a build method that invokes the ctor with the values of the
private members. Here is what the factory invocation would look like:

Frubitz furbitz = new FurbitzFactory().withName(name).withWeight
(weight).withAge(age).build();

Aaaaaaargh! I absolutely hate this style.

The ctor of the factory initialises all the private data members with
default values. If any of the 'with' methods are not called then 'build'
will use the default value.

One of the reasons they say this is better is that you can see from the
setter names what the parameters are. I prefer to make the meaning of
parameter clear by giving them clear descriptive short names. Another
reason they say is that you can employ default values for any ctor arg
you don't want. In that case I would have to decide whether or not it
makes sense for objects of that class to allow construction in that way.
If it does then I would overload the constructor.

If you have a class with a big hairy constructor, then they have a point.
But if you have such a class, you should be refactoring so that you don't.

tom

 

[Tom Anderson]

Please excuse this being off-topic. I admit this is not special to
java but a question about programming generally. [if there's a better
newsgroup please let me know which one!]

comp.theory is probably a good place

comp.object might be better. I think comp.theory is more
computer-sciencey.

(I am not a denizen of said newsgroup, so I can't say for sure).

Ditto!

tom

 

[Lew]

No. They would say they don't have the time and that I should read
GoF.

That sounds like a dodge offered by someone who doesn't know what they're
talking about. They have time to give advice but not to give reasons for it?
Oh, come on! These guys are full of bovine excrement.

Tell them to read /Effective Java/, then go do the right thing irrespective of
their crap.

 

[Mark Space]

No. They would say they don't have the time and that I should read
GoF.

This sounds bad to me. Either your mentor is not interested in
mentoring, or they are not interested in mentoring you. (I.e., they
don't value you as an employee.) Either way, time to dust off the resume.

private members. Here is what the factory invocation would look like:

Frubitz furbitz = new FurbitzFactory().withName(name).withWeight
(weight).withAge(age).build();

This is a builder pattern. At least, it can be shortened to:

Frubitz furbitz = new FurbitzFactory().name(name).weight(weight).
age(age).build();

The advantage is, if you have lots of constructor arguments, then this
allows the FurbitzFactory to check the proper configuration before
making a new one. I.e., if you forget the name or weight, it can be
checked at runtime. If you have more than three or four parameters,
then it's a good idea because supplying every possible constructor can
be very tedious and error prone.

One of the reasons they say this is better is that you can see from
the setter names what the parameters are. I prefer to make the meaning

That's a minor, although valid, advantage, imoh.

of parameter clear by giving them clear descriptive short names.

This is not really a good point. You can't name your constructor names,
for starters, and static factory names aren't always clear to the user.
Look at OpenGL for example. Yick.

Another reason they say is that you can employ default values for any
ctor arg you don't want. In that case I would have to decide whether
or not it makes sense for objects of that class to allow construction
in that way. If it does then I would overload the constructor.

Or supply a static factory method. Either way, this is 6 of one or half
dozen of the other. You can make default objects/values with any strategy.

The larger issue, imo, is code complexity. How many constructors would
you need? Is it too many to be practical?

How complicated are the objects? Are users having a tough time
configuring them correctly? Does you builder pattern add value by
checking the combinations of parameters for correctness or is just
taking up space on the page and blindly passing the parameters to mutators?

If all parameters are always required, a single constructor static
method would be preferable, imo.

Is the builder ultimately less complex or more complex than just using
constructors or static factory methods?

 

[Arne Vajhøj]

Indeed, just as the GoF have it in their description of AFDP.


But that is not the case here.

Maybe.

But I would recommend deciding based on the nature
of the class not whether it is subclassed today. Things
change over time.

Arne

 

[Arne Vajhøj]

Hmm. Ask them again at lunch. This sounds a lot to me like "i read that
factories are a good idea, and i'm too stupid to actually think about
it, so i'm going to use them and refuse to explain my decision".

Unfortunately that it seen way too often.

Arne

 

[Arne Vajhøj]

That's not what they have. They have a factory that has private data
members for all those ctor args, and setter methods for each of them,
and a build method that invokes the ctor with the values of the
private members. Here is what the factory invocation would look like:

Frubitz furbitz = new FurbitzFactory().withName(name).withWeight
(weight).withAge(age).build();

That seems rather pointless to me.

One of the reasons they say this is better is that you can see from
the setter names what the parameters are. I prefer to make the meaning
of parameter clear by giving them clear descriptive short names.

You can only see that in the declaration not in the call.

But I don't think it is enough reason to use that "factory builder".

Another reason they say is that you can employ default values for any
ctor arg you don't want. In that case I would have to decide whether
or not it makes sense for objects of that class to allow construction
in that way. If it does then I would overload the constructor.

I would also overload the constructor in that case.

Arne

 

[Arne Vajhøj]

The class being created is a simple concrete class with no interface
and no hierarchy.

Today. You never know in 1 or 5 years.

As and
when the ctor arg list ever gets extended a factory-based approach
would have to deal with this issue too. This would involve visiting
each bit of code that used the factory to ensure the extra parameters
were supplied.

With their approach: yes.

With a configuration based approach: no.

Arne

 

[marlow.andrew]

This sounds bad to me.  Either your mentor is not interested in
mentoring, or they are not interested in mentoring you.  (I.e., they
don't value you as an employee.)  Either way, time to dust off the resume.

I don't have a mentor. And I am a contractor. And I have read GoF,
several times, years ago.

This is a builder pattern.  

Yes, I know.

The advantage is, if you have lots of constructor arguments, then this
allows the FurbitzFactory to check the proper configuration before
making a new one.  

But that's not what they are doing. They did not employ the pattern
for that purpose.

That's a minor, although valid, advantage, imoh.

Agreed. And that was my point.

You can make default objects/values with any strategy.

In this particular case on this project for this class it does not
make sense to be able to construct the object using default
parameters. Hence there is only one ctor where all the values required
have to be passed.

The larger issue, imo, is code complexity.  How many constructors would
you need?  

Just one.

How complicated are the objects?  

The object is not complicated at all. It is a very simple POJO.

Does you builder pattern add value by
checking the combinations of parameters for correctness

It's not *my* builder. And the answer is "no".

or is just
taking up space on the page and blindly passing the parameters to mutators?

No. The builder has the same private data members that the class-to-be-
built has. The 'with' methods populate those private data members, the
'build' method passes them to the ctor of the class-to-be-built.

If all parameters are always required, a single constructor static
method would be preferable, imo.

Well, that would *work*, of course, but what's wrong with just using
the ctor to construct the object?

Is the builder ultimately less complex or more complex than just using
constructors or static factory methods?

My argument is "why have a builder at all?". When one has a class that
is a very simple POJO I would use its one single simple ctor to build
one. I would not create a builder class.

Regards,

Andrew Marlow