Design Patterns

[Eric Sosman]

Maybe someone can come up with an SCSE where a singleton is needed.

Runtime.getRuntime().exit(0);

 

[Stefan Ram]

Runtime.getRuntime().exit(0);

The library (Java SE) could have been defined to allow:

class Main
{ public static void main( final java.lang.Runtime runtime )
{ runtime.println( runtime.getArgc() + " command-line arguments." );
runtime.exit(); }}

or - with less changes to the current state of Java - to allow:

Runtime.exit( 0 );

 

[Daniel Pitts]

Other have.

GoF has it.

Spring has had it since 1.x.

EJB got it in 3.1.

Implementations and usage are very different, but the idea of
everybody using the same object is the same.

Arne

I think the real anti-pattern is the common implementation of how to get
the value of the singleton. Singleton's are useful, but when the
singleton status of an object is enforced beyond reason, you end up with
with all kinds of "work-arounds" to the fact that the object is a
singleton. Dependency Injection can help alleviate some of those
problems, by making the singleton nature of the object a consequence of
it only being instantiated by the framework, rather than by the class
itself being a "singleton class".

 

[Eric Sosman]

The library (Java SE) could have been defined to allow:

class Main
{ public static void main( final java.lang.Runtime runtime )
{ runtime.println( runtime.getArgc() + " command-line arguments." );
runtime.exit(); }}

or - with less changes to the current state of Java - to allow:

Runtime.exit( 0 );

A singleton class can be transformed into an uninstantiable
class having only static methods. An uninstantiable class with
only static methods can be transformed into a singleton class.
The two designs are duals: Why should one be deprecated and the
other preferred?

If all-static vs. singleton is the most pressing problem
someone faces, he has an easy life indeed!

 

[Stefan Ram]

A singleton class can be transformed into an uninstantiable
class having only static methods.

Static methods cannot be passed via reference or used to
implement interfaces. Therefore, there is a need for
non-static methods sometimes. But this does not mean a
singleton, I am thinking of a POJO first and foremost
until someone shows me where a POJO does not suffices,
but a singleton is needed.

 

[Lew]

OK, I know I'm probably still being ignored because I've upset some
people but can someone please explain to me exactly what a 'static
class' is (WRT Java of course)

RTFM:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.5.1

The original statement was inaccurate, as you point out.

What he meant must have been something like "except for static methods, which cannot
implement an interface".

I also made an inaccurate statement on this matter, as your example shows.

 

[Lew]

Static methods cannot be passed via reference or used to

Do you mean "via a reference to their owning instance"?

implement interfaces. Therefore, there is a need for
non-static methods sometimes. But this does not mean a
singleton, I am thinking of a POJO first and foremost
until someone shows me where a POJO does not suffices,
but a singleton is needed.

Most of the time, at least, it suffices to have only one instance of a class where
otherwise one might be tempted to implement a Singleton.

I have a strong bias toward using instance methods over static methods, in part because
they can implement an interface method. It does not suffice that the method merely
doesn't access instance state. It also needs to be "global" by design.

Instance methods can be easier to control in multi-threaded contexts. It's often good to
have a manager instance that controls the methods so that different units can use them
independently.

If you later decide that "singleton" was a mistake, instance methods don't need to be
refactored.

There's also a circular analysis where type state is maintained in mutable static variables, so one
creates static methods on the theory that they don't access instance state.

The risk of mistake with instance methods is lower than with static methods.

So if I have a compelling argument for making a method static, fine, but tie or a close second
goes to the instance implementation.

 

[markspace]

OK, I know I'm probably still being ignored because I've upset some
people but can someone please explain to me exactly what a 'static
class' is (WRT Java of course)

Part of the reason I'm generally ignoring your posts is that you don't
look obvious stuff up with Google. If you had said "I searched for
'static Java class' but didn't really understand the results," that
would a bit different. But at least trying to look stuff up is pretty
basic.

That said, I think people are using the term loosely and expecting the
reader to fill in the gaps. A real static class is a nested class that
has no (implied) reference to its enclosing instance.

<http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html>

What's being referred to up-thread is just a class with all static
methods which also has no public constructor. (I think, I'm not really
reading this discussion closely.) It's a standard pattern in Java which
is used to make "utility classes." c.f. java.lang.Math, which does
exactly this.

The standard pattern is:

public class UsefulUtils {
private UsefulUtils() {}

... public static methods here

}

This class is effectively final because without a public ctor it cannot
be extended. If this class is stateless or has no mutable state, then
it is also thread safe, absent some other use of globals.

 

[Stefan Ram]

A real static class is a nested class

that has

whose instances have

no (implied) reference to

its enclosing instance.

their enclosing instances.

BTW: A static class has a reference to its enclosing class.

public class Main
{ static class C {}
public static void main( final java.lang.String args[] )
{ java.lang.System.out.println( C.class.getEnclosingClass() ); }}

 

[markspace]

whose instances have



their enclosing instances.

BTW: A static class has a reference to its enclosing class.

"Class object." It's splitting hairs a bit, but that is how the JLS
refers to them.

Example:

"In the Java virtual machine, every object belongs to some particular
class: the class that was mentioned in the creation expression that
produced the object (§15.9), or the class whose Class object was used to
invoke a reflective method to produce the object..."

public class Main
{ static class C {}
public static void main( final java.lang.String args[] )
{ java.lang.System.out.println( C.class.getEnclosingClass() ); }}

C.class is a class object. "Class" as I use it above (usually with a
lower case 'c') is more the concept of a class, rather than its Java
implementation of the class. (Rather the same way that the JLS uses
'class' to refer to the general concept of a class in OOD, for example
that section of the JLS I quoted above.)

That said, you're not really wrong to point out it's really the
instances that have references to their enclosing class.

 

[Arved Sandstrom]

I think the real anti-pattern is the common implementation of how to get
the value of the singleton. Singleton's are useful, but when the
singleton status of an object is enforced beyond reason, you end up with
with all kinds of "work-arounds" to the fact that the object is a
singleton. Dependency Injection can help alleviate some of those
problems, by making the singleton nature of the object a consequence of
it only being instantiated by the framework, rather than by the class
itself being a "singleton class".

Exactly so. Let it be a "singleton" only because an external framework
is tracking that there is one instance, and you obtain the instance via
the framework.

AHS

 

[Arne Vajhøj]

I think the real anti-pattern is the common implementation of how to get
the value of the singleton. Singleton's are useful, but when the
singleton status of an object is enforced beyond reason, you end up with
with all kinds of "work-arounds" to the fact that the object is a
singleton.

What workarounds are you thinking of?

Arne

 

[Arne Vajhøj]

Nitpick: "static class" is the wrong term. I figure you mean a "utility class",
or class with only static members.


Static classes certainly can implement interfaces. It's non-instantiable
classes that can't, and classes containing only static methods.

I think you can assume he use "static class" in the C# meaning not the
Java meaning.

Arne

 

[Arne Vajhøj]

OK, I know I'm probably still being ignored because I've upset some
people but can someone please explain to me exactly what a 'static
class' is (WRT Java of course)

This is illegal

public static class Foo{...

a class with all static methods certainly can implement an interface

This compiles

public class Foo implements Serializable{
public static void Bar(){
}
}

In Java you can use:

package demo;

public class Foo {
public static class Bar {
...
}
...
}

in which case Bar is just a class with the name
demo.Foo.Bar.

You can also have:

package demo;

public class Foo {
public class Bar {
...
}
...
}

in which case instances of Bar is tied to instances of
Foo (access to its members).

In C# you have:

namespace Demo
{
public class Foo {
public class Bar {
...
}
...
}
}

which is the equivalent of the first Java example (with static).

You can also have:

namespace Demo
{
public static class Bar {
...
}
public class Foo {
...
}
}

in which case Bar is a class that can only have static methods
(and can not implement interfaces).

Arne

 

[Arne Vajhøj]

RTFM:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.5.1

The original statement was inaccurate, as you point out.

What he meant must have been something like "except for static methods, which cannot
implement an interface".

He just left out "C#" in the text.

Arne

 

[Arne Vajhøj]

A singleton class can be transformed into an uninstantiable
class having only static methods. An uninstantiable class with
only static methods can be transformed into a singleton class.
The two designs are duals: Why should one be deprecated and the
other preferred?

I would in most cases with more serious code prefer singleton
due to its interface capability.

For throw away code I would probably go for the static just
because I am a lazy bastard.

If all-static vs. singleton is the most pressing problem
someone faces, he has an easy life indeed!

I agree with that.

Arne

 

[Arne Vajhøj]

Maybe someone can come up with an SCSE where a singleton is needed.

Needed as in "problem can not be solved without"? I doubt such exist!

Needed as in "a large of programmers prefer it to solve the problem"?
There are many. Connection pools, configuration settings, web app
statistics etc..

Arne

 

[Lew]

I think you can assume he use "static class" in the C# meaning not the
Java meaning.

Wait, isn't this comp.lang. *java* .programmer?

I'm in the wrong newsgroup!

No, we do not assume any such thing.

 

[Arne Vajhøj]

Wait, isn't this comp.lang. *java* .programmer?

I'm in the wrong newsgroup!

It happens that other languages come up here.

No, we do not assume any such thing.

Well - his description fit with C# semantic and it is
rather well known that he uses C#, so it would be a
very natural assumption.

Arne

 

[Daniel Pitts]

Needed as in "problem can not be solved without"? I doubt such exist!

Needed as in "a large of programmers prefer it to solve the problem"?
There are many. Connection pools, configuration settings, web app
statistics etc..

Logging is another one. They thing about all those is that there is a
globally accessible shared instance, but that doesn't have to be
enforced by the class itself. Rather, the life-cycle of the object is
managed externally.

Self-managed life-cycles should be very rare. For instance, something
which actually manages external resources may need to enforce some
invariants about its life-cycle, in order to manage external state in a
sane manor. This isn't something an application programmer need worry
about on a frequent basis.

I'm *not* a fan of a global Configuration object for many reasons. One
is that the configuration class becomes overly involved with the rest of
the application. At least, if they treat it as a place to "go grab some
settings". If the settings are injected, then that's a different story.