Re: relationship of Factory method and singleton design patterns?

From: Mark Nicholls (nicholls.mark_at_mtvne.com)
Date: 11/30/04 

Date: Tue, 30 Nov 2004 12:16:08 -0000

"Daniel T." <postmaster@earthlink.net> wrote in message
news:postmaster-A92DD3.23050929112004@news1.east.earthlink.net...
> jrefactors@hotmail.com (Matt) wrote:
>
> > what's the differences between factory method and singleton? and
> > relationships?
>
> A factory method is one that invariably creates an object. IE each
> object returned from the factory method has a different identity. To put
> it in code: assert( Class.factory() != Class.factory() )
>
> With a singleton's "getInstance" method, the opposite is true, every
> call to getInstance returns the exact same object. IE assert(
> Class.getInstance() == Class.getInstance() )

To me this is a strong definition of a factory (and in a sense bizarrely a
strong definition of a singleton!).

I accept it is the text book (GoF) definition, but a more powerful use is to
leave the more of the policy of creation to the factory itself....if
possible.

both mechanisms define a way to access an object, to me the singleton, or
not, nature of the returned class should ideally be the business of the
service factory class, the client should ideally be ignorant of this (an
example in my world is the .net remoting infrastructure, where classes can
be marked as singleton or single call, from the client perspective there is
sometimes (and hopefully often) be decoupled from the client logic, though
in this context it implies a stateless interaction).

The weak definition is simply defined by the class interface, unfortunately
this may be confusing to the client if he 'believes' a factory will always
create a new object when in fact it only returns a singleton (or a pooled
one, or some other policy defined on the access to 'new' objects), but this
has never caused me a problem.

In the real world a factory that returns a singleton is not generally a
problem, as long as the singleton itself makes no promises that could be
violated by multiple client access .A singleton that returned new objects
would be more troublesome...but then I never use the singleton pattern
myself.

P.S.

similarly in the LoD discussions a 'page' that returns it's contents, if it
returns a readonly clone, then that would seem like it's own business, yet
technically it would be a factory.

Relevant Pages

  • Re: Opinions on the Law Of Demeter
    ... >> But the point of combining the factory and singleton was ... >> without the client knowing whether it returns a singleton ... of connections through the single instance. ...
    (comp.object)
  • Re: Singleton
    ... I don't usually go to a string factory or a list factory to ... If you have an abstract DOM interface, for example, and the implementation ... To me it's very clear to go to the DomFactory or singleton ... As mentioned in my posting you unit test a class separate from the ...
    (comp.object)
  • Re: using the "static" keyword to implement the Singleton pattern
    ... I didn't mean a factory class that returns the singleton. ... > factory method in the client object is usually private, ... separate Authoriser and Authorisation. ...
    (comp.lang.php)
  • Re: Software design patterns: encapsulation & object identity
    ... >> constructs, maintains, and issues GOF Singleton instances of a Widget. ... >> Clients of the Factory instance obtain the Widget Singleton instance ... >> APIs) the fact that the instances issued to clients are Singletons? ...
    (comp.object)
  • Re: Software design patterns: encapsulation & object identity
    ... > constructs, maintains, and issues GOF Singleton instances of a Widget. ... > Clients of the Factory instance obtain the Widget Singleton instance ... instantiating client, can know that the factory creates singletons. ...
    (comp.object)