Re: Software design patterns: encapsulation & object identity

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/08/04 

Date: Wed, 08 Dec 2004 16:29:12 GMT

Responding to AB...

> Please consider a GOF Factory class (C++ implementation) that
> constructs, maintains, and issues GOF Singleton instances of a Widget.
> Clients of the Factory instance obtain the Widget Singleton instance
> from the Factory.
> Memory management is the responsibility of the Factory - the Widget
> Singleton is destroyed by the Factory upon deletion of the Factory.
>
>>>From a design-principle perspective:
>
> 1. Is it important for the Factory to publish (e.g. document on public
> APIs) the fact that the instances issued to clients are Singletons? Or
> should this information be 'kept secret' beyond the internal confines
> of the Factory?

The need for a single instance is a business rule that the Singleton
encapsulates in its implementation. That is nobody else's business --
not even the Factory that creates the Singleton object itself.

This is no different than, say, the Withdraw responsibility on
CheckingAccount. Whether the withdrawal is executed using an overdraft
or not is none of the client's business. Nor is it any business of the
Factory that creates the CheckingAccount.

>
> 2. Similarly, might clients justifiably require unique non-Singleton
> instances from a Factory for some particular type of Widget, or would
> such a requirement represent an implementation constraint that the
> client is not entitled to impose on the Factory?

The Factory creates an instance of Singleton, not the Widget instances
that the clients request. If another sort of Widget is not restricted
to a single instance, then the Factory should not construct a Singleton;
it should construct those Widgets directly.

[Note that Singleton is, itself, a kind of factory. That's why it is
included with the other constructor patterns in the GoF book. So
"Factory" in your context (1) is really creating another factory.]

>
> 3. What would be the most appropriate public API names(s) for the
> Factory interface(s)? What would constitute a bad API name? Starter
> candidates include GetWidget(), MakeWidget(), WidgetInstance(). I
> anticipate the answer being partially related to 1 & 2.

Without additional problem context information, I would probably opt for
createWidgetXSingleton for (1) and createWidgetY for (2).

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • 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: 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: 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)
  • Re: relationship of Factory method and singleton design patterns?
    ... > A factory method is one that invariably creates an object. ... strong definition of a singleton!). ... be marked as singleton or single call, from the client perspective there is ...
    (comp.object)