 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
TimOnGoogle
Guest
|
 Posted: Thu Aug 25, 2005 12:14 am Post subject: Singleton or static public references? Which do you prefer? |
 |
|
I'm at a new job, and I'm going to be re-working some code into a new
form. The current code, however, is rife with things like this:
public class Class_A {
public static String someValue;
public Class_A() {
if (X) {
someValue = Y;
} ...
...
}
public class Class_B {
public void myMethod() {
if (Class_A.someValue == X) {
...
}
}
}
In some cases, the value Class_A.someValue is set only upon
initialization. In others, it is set to different values throughout
the running of the application.
This kind of thing makes me want to slap whoever wrote it silly! I
have always thought that this is the exact sort of situation where you
should be using a Singleton pattern with synchronized methods, because
1) it's cleaner, and 2) it will stop any conflicts in a multi-threaded
environment (which this is).
The engineers here don't seem to think this is a big deal, but it makes
me want to pull my hair out!
What are your opinions on this? Am I crazy to think this is just Bad
Programming(tm)?
- Tim
|
|
| Back to top |
|
 |
Sebastian Scheid
Guest
|
| Posted: Thu Aug 25, 2005 7:40 am Post subject: Re: Singleton or static public references? Which do you pref |
|
|
"TimOnGoogle" <fromGoogle (AT) apeshit (DOT) com> schrieb im Newsbeitrag
news:1124928885.360849.106580 (AT) g49g2000cwa (DOT) googlegroups.com...
| Quote: | I'm at a new job, and I'm going to be re-working some code into a new
form. The current code, however, is rife with things like this:
public class Class_A {
public static String someValue;
public Class_A() {
if (X) {
someValue = Y;
} ...
...
}
public class Class_B {
public void myMethod() {
if (Class_A.someValue == X) {
...
}
}
}
|
Uuuuh...
You'll have fun applying even the basic refactorings like encapsulate field
to the code.
| Quote: |
In some cases, the value Class_A.someValue is set only upon
initialization. In others, it is set to different values throughout
the running of the application.
This kind of thing makes me want to slap whoever wrote it silly! I
have always thought that this is the exact sort of situation where you
should be using a Singleton pattern with synchronized methods, because
1) it's cleaner, and 2) it will stop any conflicts in a multi-threaded
environment (which this is).
|
That does not need to be true. Even such a simple thing as a Singleton
should be used with care! It has drawbacks and should only be used if you
are sure that there MUST NOT be more than one instance of this class. Often
one only HAS one instance of a class (at a particular time in development or
design) and makes it a Singleton due to convenience reasons. But than you
have to be aware of the drawback too.
A Singleton is not per se cleaner and thread-safer than a class with static
members and methods.
What would be cleaner in this case:
1. Encapsulate all the public fields
2. Think about thread-safety which must not necessarily mean that all the
methods are synchronized. Particularly if you expect heavy usage of this
class there are better solutions with respect to performance. "Effective
Java" has a good chapter about threads (and of course there is Doug Lea's
bible).
3. Think hard about making this class a Singleton. A bullet-proof Singleton
cannot be subclassed and cannot be changed. That often makes unit-testing
where you want to use mock objects very difficult. You can deal with that by
using Strategy in the Singleton which makes things more complicate.
| Quote: | The engineers here don't seem to think this is a big deal, but it makes
me want to pull my hair out!
What are your opinions on this? Am I crazy to think this is just Bad
Programming(tm)?
|
If the whole program looks like the code above that would be a disaster. I
would than expect that the original author did neither use any OO basics nor
principles nor wrote any unit tests. Depending on the size of the program
you have a chance by refactoring the code or at least parts of it. But it
may be very difficult and a lot of work to write unittests for that thing.
And depending on the tasks you are instructed to do (maybe only very few
extensions) it might be acceptable to just leave it in this state, do your
work and never touch it again.
But building great extensions would be no fun without doing some refactoring
and unittesting before by which you will even gain a better understanding of
the whole program.
Regards
Sebastian
|
|
| Back to top |
|
|
Oliver Wong
Guest
|
| Posted: Fri Sep 02, 2005 6:25 pm Post subject: Re: Singleton or static public references? Which do you pref |
|
|
"TimOnGoogle" <fromGoogle (AT) apeshit (DOT) com> wrote
| Quote: | I'm at a new job, and I'm going to be re-working some code into a new
form. The current code, however, is rife with things like this:
public class Class_A {
public static String someValue;
public Class_A() {
if (X) {
someValue = Y;
} ...
...
}
public class Class_B {
public void myMethod() {
if (Class_A.someValue == X) {
...
}
}
}
In some cases, the value Class_A.someValue is set only upon
initialization. In others, it is set to different values throughout
the running of the application.
This kind of thing makes me want to slap whoever wrote it silly! I
have always thought that this is the exact sort of situation where you
should be using a Singleton pattern with synchronized methods, because
1) it's cleaner, and 2) it will stop any conflicts in a multi-threaded
environment (which this is).
|
There is not enough information for me to determine whether I think this
is a good design or not. That is to say, I believe there exist times when it
makes sense to declare a field to be static and public. In the case where
the static field is set only once upon initialization, I recommend it
additionally be declared as final.
As for multi-threaded issues, I'm not sure what you mean by "Singleton
pattern with synchronized methods", but if you mean making the
"getSoleInstance()" method synchronized, I think this adds no level of
safety above plain static fields.
- Oliver
|
|
| Back to top |
|
|
Roedy Green
Guest
|
| Posted: Mon Sep 05, 2005 7:01 am Post subject: Re: Singleton or static public references? Which do you pref |
|
|
In general the advantages of static are:
1. speed.
2. simplicity.
The advantages of the singleton:
1. you can create variants that inherit the singleton class. With
static there is no overriding or supering.
2. you can label it a design pattern and impress your boss.
3. You can sometimes postpone initialisation indefinitely.
4. If you later discover you need more than one "singleton" you can
modify the code with minimal effort.
5. for multithread work, you can lock the singleton rather than the
entire class.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
|
|
| Back to top |
|
|
Roedy Green
Guest
|
| Posted: Mon Sep 05, 2005 11:48 pm Post subject: Re: Singleton or static public references? Which do you pref |
|
|
On Mon, 05 Sep 2005 16:11:06 +0100, Thomas Hawtin
<usenet (AT) tackline (DOT) plus.com> wrote or quoted :
| Quote: | Classes load lazily without any checking code.
with a singleton you get a two stage initialisation. You get a mini |
init with the class and a maxi, possibly procrastinated init with the
singleton(s).
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
|
|
| Back to top |
|
|
Roedy Green
Guest
|
| Posted: Mon Sep 05, 2005 11:50 pm Post subject: Re: Singleton or static public references? Which do you pref |
|
|
On Mon, 05 Sep 2005 16:11:06 +0100, Thomas Hawtin
<usenet (AT) tackline (DOT) plus.com> wrote or quoted :
| Quote: | 5. for multithread work, you can lock the singleton rather than the
entire class.
I don't think there is any significant difference here.
|
The idea is if the class is bottleneck for locking, sometimes you get
get twice the throughput by locking two different singletons instead
for disjoint purposes.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
