Yeah. I was aware that I was asking a rather broad question;
thanks for the effort you put into your answer.

Unsurprisingly, I agree with everything on this list.

But some of these make me nervous. I'm kind of like
pass-trhough parameterization; no surprises, and I know
at a glance what objects are involved in the method. I
do with Java had better (well, any) meta-syntax facilities,
so you could replace a verbose and un-informative method
delegation with a simple pointer to the class you're delegating
too.

I've already proposed a different solution to the
ambient environment that's conceptually quite similar;
the biggest difference that I can see is that I'm proposing
to explicitly pass the enviroment object around to anything
that needs it.

A matter of taste, of course.

I'm actually largely okay with immutable static fields ...
really, immutable anything that can be assigned a final
value at compile time. Relaxing that restriction to
assign-only-once fields at least is enough to completely
avoid the spooky action at a distance problem, where the
behavior of one part of the program changes when a not-
obviously-related part makes a change to a shared value.

In this context, when I say "testing", I'm talking about constructing
unit tests, not discovering and fixing problems. I apologize for being
unclear.

... <snippage> ...

<snip handy rules of thumb>

As someone relatively new to Java I can see the sense in what you are
saying but I can't see how else to implement certain things.

I think I have three or more areas where I'm either using singletons,
where singletons would be useful, or where I am doing something that I
think is related (but I may be misunderstanding) Maybe someone could
suggest best practice for some or all of these? ...

1) Constants that are used in several classes. In one case these are key
values for user preferences that I am storing in a properties file. For
example 'static String WINDOW_SIZE = "window_size";'. By using the
constant, the compiler will pick up any typing errors, If I type
'prop.get("window-size");' I'll not get a compiler error, may not get a
run-time error but will get unexpected behaviour. So in my class that
contains my main() I define these as static constants. Elsewhere I use
these constants as prop.get(MainClass.WINDOW_SIZE) etc. These are
clearly global, I don't see a cleaner alternative.

2) Shared single resources. My example is a database connection. My app
opens one connection, various classes use this to perform SQL
transactions on unrelated tables etc. I could add a `connection`
variable to every method call, but this makes for long strings of
arguments to method calls, in some cases just so the variable can be
passed on to other method calls (covered in Chris's rules of thumb).
So I have a singleton to create the connection and it provides a public
DBClass.getConnection() to return the connection. Obviously I have to be
careful to avoid concurrent use of the connection. I don't know of a
better way to share a single resource of this sort - is there one?

3) An "owner" for JDialogs. My App has a single frame. Many classes need
to popup modal Dialogs or JOptionPanes, these need an owner to be
specified. Currently I'm passing it as a parameter to the constructor of
any class that needs it. I'm not entirely happy with this approach. The
alternative seems to have a static variable MainClass.frame. Is there a
better approach?

4) As an aside to the above, I sometimes need various classes to be able
to things done by the main class, for example, update a status message
at the bottom of the main window. To achieve this I pass a reference to
the main JFrame in the constructor of classes created. So sometimes I
have ...

class Mainform extends JFrame {
    Mainform() {
        ...
        FooClass f = new FooClass(this);
        BarClass b = new BarClass(this);
        ...
    }
    public void setStatus(String text) { ... }
}
class FooClass {
    JFrame parent;                     // *** Note "JFrame" ***
    FooClass(JFrame parent) {
        this.parent = parent;
    }
    xyzzy() {
        ...
        JOptionPane.showMessageDialog(parent, "Error" ...);
        ...
    }
}
class BarClass {
    Mainform parent;                     // *** Note "Mainform" ***
    BarClass() {
        this.parent = parent;
    }
    plugh() {
        ...
        parent.setStatus("Important thing accomplished");
        ...
        JOptionPane.showMessageDialog(parent, ...);
        ...
    }
}
Having a Mainform variable in the constructor of BarClass means I can't
re-use the BarClass in another application. I also have this
JFrame/Mainform choice for parameter type that I find hard to resolve.
Any suggestions?

Sorry for droning on, I hadn't intended to be this wordy :-) Feedback
appreciated though.

On Nov 28, 3:44 pm, "Chris Uppal"
<chris.up...@metagnostic.REMOVE-THIS.org> wrote:

snipped...

Its not so much as they make it difficult, its that they make the tests
brittle at best, or enforce an execution order of them at worst.

The usual way around these issues is to add some form of 'reset'
mechanism to the Singleton, so that each unit test can 'reset' the
state of the singleton before starting.

However, the better approach is to have the code under test, not know
that the object is a Singleton, by passing it to the code, instead of
the code using the static 'getInstance()' method.

If we then start passing around the Singleton instance to use, instead
of using its static fetch method, then we should ask ourselves...
"Why don't I just create one instance, instead of forcing a Singleton?"

Singletons (IMO) are best used as a global Container for various other
objects. AKA a Toolbox.

In 10 years of development I've rarely found a real need for enforcing
the 'must only be one' concept, that the Singleton is designed for.  I
have seen countless usages of Singleton, as a way of accessing from
anywhere, a certain type of object, or values it holds.

Andrew

You may not have meant that exactly how it sounded, but if you do then I
disagree profoundly.  A good design is created on its own merits, /not/ by
scanning some menu of available patterns.

   -- chris