• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Encapsulate Classes with Factory

 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am going through a Refactoring site reading
Classes with Factory. From what I understand, here is the code for it as per the diagram, the intent being "Make the class constructors non-public and let clients create instances of them using a Factory."


I am a little confused with this. Normally, we have a factory class which returns instances confirming to an interface. In this case the interface is a class and the class itself has factory methods , forBoolean() and forString(). Secondly the concrete classes extends from the generic class - AttributeDescriptors restricting them from inheritng any other behavior. I am not really sure about the benefits of this approach, if at all I have coded correctly with respect to the
diagram

Regards,

Nikhil
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general, some classes are not expected to be created from *outsiders*.

If you make the constructor be *default*, then, only the classes with the same package can access it. Thus, the Factory class, and the object class should be in the same package.

In such case, in case you want to create an object, the only way to do is via the specific Factory.

Nick
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To me, that's a perfectly valid implementation of the Factory Method pattern.
I also can't see anything wrong with using an abstract class as a replacement for an interface. And when something starts holding you back, you refactor
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
To me, that's a perfectly valid implementation of the Factory Method pattern.



Well, no, it's not. In the Factory Method pattern, the factory method is declared abstract and called polymorphically in the base class, implemented differently in subclasses. The example above just shows static creation methods.
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think an interesting aspect of the above pattern is the fact that the root of the class hierarchy knows about all of its children (and so changing one implementor will imply modification in two places :-|).
However, I have used this with a small hierachy of validators:
<<interface>> IValidator
<<abstract>> AbstractValidator -> this is also a factory
... specialized validators


./pope

[ September 10, 2004: Message edited by: Ali Pope ]
[ September 10, 2004: Message edited by: Ali Pope ]
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Daniel Mayer:
Well, no, it's not. In the Factory Method pattern, the factory method is declared abstract and called polymorphically in the base class, implemented differently in subclasses. The example above just shows static creation methods.

Ah. You're absolutely right.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It may not be much of a factory now, but it could turn into a proper factory without telling any clients. Frinstance, the forBoolean method might use configuration or current state or day of the week to decide between several implementations instead of the one it has today. If it gets at all complex, it might call to a separate factory class.

Making a class act as a factor for itself is a nice trick if you think a factory might be useful in the future. You don't have the overhead of an interface and factory class, but you can plug them in later with no pain to the clients.

Recommended here: Encapsulating Construction
 
author
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm also of the opinion that there if nothing wrong with a class being its own Factory for a time. If the class becomes too heavy with its own responsibilities and the responsibilities of creation, you can always apply Extract Factory (which is the same as Extract Class).

On page 70 of the book, I discuss how I define a Factory and how I distinguish it from a Factory Method and an Abstract Factory.
reply
    Bookmark Topic Watch Topic
  • New Topic