[Rxtx] sole of a new design pattern

[Dr. Douglas Lyon]

Hi All,

First, I would like to thank David for his
prompt and thoughtful remarks. I had no
idea people that feel strongly about a design patterns!

Wow!

Feedback (particularly critical feedback) is greatly appreciated.

Starting at the end, first:
>I did use it in
>the past, but now I've been exposed to the   shortcomings of the 
>Singleton pattern, so I limit
myself to Factories.

David, if I understood your comments correctly,
you suggested that Factories can be
used in leu of the Singleton Design Pattern,
or even the Parametric Singleton Design Pattern.
As I see in [Gof]:
Factory Method:
Intent
"Define an interface for creating an object, but let subclasses
decide which class to instantiate. Factory Method lets a class defer
instantiation to subclasses."

The Singleton Design Pattern is a concrete class, which is rather
different, right? Also, subclasses are not permitted with Singleton,
as they are final.

Naturally, I could use an abstract factory as a parent for
a singleton. I could even design a facade that could be implemented
with the singleton....but that is not the intention of the design.
Unless you want a mock-up, as discussed, below:

More below:
>Hello,
>
>>  The Parametric Singleton Design Pattern
>
>The Singleton is the most abused design pattern ever. Good use-cases 
>for this pattern are extremely
>rare and mostly confined to problems related to hardware resources, 
>like serial ports.
>
><snip>
>>  Applicability
>>
>>  Use the Parametric Singleton Design Pattern when:
>>    1. There must be exactly one instance of a class with the given
>>  parameters.
>OK. As I said above, this case this actually very unusual. The 
>Singleton pattern is mostly used when :
>>    2. The instances must be accessible to clients from a well-known
>>  access point.
>
>Using the singleton pattern in this case is just convenient for the 
>programmer. Problems arises
>pretty quickly, especially if you attempt to unit-test your classes.
>
>1) If your singleton is stateful, or hold on to stateful objects, it 
>means that two different unit
>tests are not actually independent. Instead of starting with a brand 
>new environment, the result of
>a test may be affected by the result of a previous test. This 
>problem also arise when with your
>class relies on a database. In both cases, the solution is to reset 
>your "unique" resource
>(Singleton or database) at the beginning of the test, which is a 
>pain. Also, while most projects
>connect to a single database, projects that allow the use of 
>Singletons usually contain several of
>thems, and new ones may cropped up unnoticed. You quickly end up 
>with test cases that only pass in a
>certain order, which is a royal pain.

There are basic problems with communicating finite state machines
that include reachability and deadlock analysis. These are addressed
with petri net analysis and are beyond the scope of the design pattern.

As you quite rightly pointed out;
the parametric singleton pattern (or the singleton pattern, for that matter)
enable multiple threads to gain access to the same instance. The only
way that I can see to block others from gaining access to the reference
is the synchronize keyword. This is putting a spin-lock (or MUTEX)
on the reference.

The question of how to unit-test a design pattern like the parametric
singleton remains open. Perhaps this is a deficiency.
>
>2) You cannot mockup a singleton. Once everyone calls the 
>SomeSingleton class statically, you can't
>replace your class by SomeSingletonMockup.

Acutally, I am not sure that this is true. If the Singleton implements
a Facade interface, it should be possible to make the replacement.
Right?

>
>Furthermore, even for hardware services, the Singleton pattern does 
>not really prevent concurrent
>accesses. If you start the same program in two different JVMs, 
>unless they somehow shared the state
>of their "Singletons" (through lock files for example), the 
>Singleton pattern will not prevent
>concurrent access.

Good Point!!
You have sharp eyes!
The singleton design pattern should/could take responsibility for this. In
fact, you may notice that my code does have an implementation
(LocateRegistry) that can work across JVM's. The LocateRegistry will
even work across the Internet! LocateRegistry takes both a host name
and a Port (lock files just don't do this).

I did not think to implement this beyond the local machine, but, in
its present form, it will work across different processes.


>
>Our application uses RXTX, and we routinely encounter cases where 
>another (native) application has
>already locked the port. Since we cannot modify the native 
>application to recognize lock files,
>OS-level control is irreplaceable.

The singleton design pattern is not meant to replace OS-level control, but to
centralize the Java programmers access to it.

If lock files, for example, are used for serial ports, the Singleton 
Design Pattern
should be able to work with them.

>
><snip>
>>
>>  Consequences
>>  The Parametric Singleton Design Pattern has several benefits:
>>
>  > 1. Controlled access to parametrically defined instances. Since
>>  the Parametric Singleton class encapsulates its instances, there is
>>  control over how and when clients access it.
>
>Not really. Once you've returned the instance to a client, you've 
>lost control over it. The client
>can to whatever it wants with it. You cannot "recall" the instance 
>or claim it back.

Good point, this should read:

>  1. Controll when parametrically defined instances are created. Since
>  > the Parametric Singleton class encapsulates its instances, there is
>  > control over how and when they are instanced.

>
>>  2. Reduced name space. The Parametric Singleton pattern avoids
>>  global variables that store instances created from the same parameter.
>
>Sure, but you don't have to rely on a Singleton for that. Just 
>create a single Factory.
>
><snip>

Thank you for your thoughtful and prompt response!

Regards,
  - Doug