Design Pattern: Is the Universe Object a Singleton or Static or either way.
Hi All,
1. I've read this thread: static versus singleton
http://forum.java.sun.com/thread.jsp?forum=425&thread=401035&tstart=105&trange=15
2. Now, specifically if you were to model the Universe Object, what would you choose? a Singleton
or a Static Class or either way depending on your design point of view?
(either way depending on your design point of view imply there is more than one solution to a problem.)
Basically, I'm looking for is the justification of one (singleton) or the other (static) or doesn't matter
in addition to the pure technical pros and cons (or avantage/disavantage) of singleton versus Static (see pt. 1)
What's 'the Universe Object'? Singletons and static variables don't do the same thing. Singletons ensure there is only one instance of the Singleton class. static variables do no such thing.
Hi,
Personally, I'd make the universe a singleton. The universe is an 'object', not a class, and if alternate universes are proved to exist you can create new instances, and not treat it as a singleton any more, without much rewriting (a static implementation would need a total rewrite).
As a singleton, it can also implement interfaces, such as Collection, though I'm guessing that toArray() might be a problem to implement properly!
It would also probably be useful to treat the universe as a generic Object so that you can pass it around your code like any other object. i.e. you might want to put it in a Map. Not so easy if it's done using static methods.
Ol.
0sa at 2007-7-14 22:26:40 >
<dubwai>
What's 'the Universe Object'?
</dubwai>
Sorry, for not being clear. My assumption is that every body would undertand the word 'Universe' immediately. So with this clarification. I hope you will have more input. Thanks.
public class Universe //Singleton
{
private static Universe instance = new Universe();
private Universe()
{
}
public static Universe getInstance()
{
return instance;
}
public void do()
{
}
}
public class Universe //Static Class like Math class for example
{
public static void do()
{
}
...all other methods are static
}
--
<os>
Personally, I'd make the universe a singleton.
The universe is an 'object', not a class, and if alternate universes are proved to exist you can create new instances,
and not treat it as a singleton any more, without much rewriting (a static implementation would need a total rewrite).
</0s>
1. Keywords: Personally and alternate universes are proved to exist.
Yes, this is the kind of reasoning I'm looking for. By that I mean when we design a class, our reasonning should not depends
on the 'pure' technical concepts of what Singleton class or Static class can do but rather depending on the reality
of the world. And then from that understanding we would choose a Singleton or Static class. This is what I meant by 'Either way, it doesn't matter' which depend on one's view about of existence of the universe whether it's unique or not. In your case (Os), you prefer Singleton because of the possibility of alternate universes.
2. Now, let's admit, there is only one Universe, would you still prefer Singleton class over Static class? for all the techincal reasons that you said
"As a singleton,..."
"It would also probably be useful to treat the universe as a generic Object..."
OR just because a Singleton would be 'safer' to cover the possibility of design extension in that can cover all cases (alternate as well)
> <dubwai>
> What's 'the Universe Object'?
> </dubwai>
>
> Sorry, for not being clear. My assumption is that
> every body would undertand the word 'Universe'
> immediately. So with this clarification. I hope you
> will have more input. Thanks.
I understand the word 'universe' I but it's not a computer term per se. If I said what the best way to write 'the World class' or 'the Galaxy class' would that be enough info for you to give me useful input? Your phrasing implies there is only one way to write a class called Universe.
I misunderstood your post on one count. I thought you mean a static variable.
A 'static class', as it is sometimes called, is generally best for sets of methods that are not dependent on any sort of state. You can manage a state in a static class but it is less elegant and prone to unexpected problems. Another disadvantage is that you can't pass a 'static class' to a method. 'Static classes' are not OO.
It really depends on what Universe is supposed to do.
dubwai,
1.
::I misunderstood your post on one count. I thought you mean a static variable.
I'm here to learn how to communicate clearly as well. :-)
::Your phrasing implies there is only one way to write a class called Universe.
Actually, this is a great interpretation because it is in sync what I meant but not well expressed again.
(I have to learn to express it clearly or rather think through. :-)
<PaulPhuoc>
(either way depending on your design point of view imply there is more than one solution to a problem.)
</PaulPhuoc>
2.
::It really depends on what Universe is supposed to do.
Now, what would your Universe be? (Of course, a simplified picture but if you can, magnify it. :-) )
In that I mean would you choose a Singleton or a Static beside your cited technical reason
"A 'static class', as it is sometimes called...'Static classes' are not OO."
> Now, what would your Universe be? (Of course, a
> simplified picture but if you can, magnify it. :-) )
> In that I mean would you choose a Singleton or a
> Static beside your cited technical reason
> "A 'static class', as it is sometimes called...'Static
> classes' are not OO."
'The Universe' could be two dimensional. 'The Universe' might be a class that has nothing to do with the physical universe but is rather, 'the Universe' that a porgram runs in.
There are an inifinte number of ways to write 'the Universe' class. Your assumption that just saying I'm writing 'the Universe' will tell someone anything useful is mind-bogglingly naive. For example. I might write a Dog class and you might write a Dog class and they could look nothing alike and be used for completely different purposes.
Is your program a graphical simulation of 'a universe'? Then you might not even need 'the Universe' as a class. The universe is implied by the program. Or you could call your main UI class 'the Universe'.
What methods are you going to have on 'the Universe'?
universe:
1. All matter and energy, including the earth, the
galaxies, and the contents of intergalactic space,
regarded as a whole.
2.
a. The earth together with all its inhabitants
and created things.
b. The human race.
3. The sphere or realm in which something exists or
takes place.
4. Logic. See universe of discourse.
5. Statistics. See population.
dubwai,
Basically, What you said is before deciding what is needed technically, we need to understand the
requirement and define/clarify the terms/concepts used to have a common ground of understanding
otherwise there will be any possible interpretation or misinterpretation.
Am I interpreting your words correctly?
dubwai I think we're posting simultaneously in that I did not see your last post "universe..." Aug 21, 2003 1:13 PM when I replied to your post Aug 21, 2003 1:02 PM
> dubwai,
>
> Basically, What you said is before deciding what is
> needed technically, we need to understand the
> requirement and define/clarify the terms/concepts used
> to have a common ground of understanding
> otherwise there will be any possible interpretation or
> misinterpretation.
>
> Am I interpreting your words correctly?
Bascially. You don't start a design my saying, "these are the class names, how should I write those classes?" You start designing the application at a high level and then dig down. You might find that the universe concept on your application may be implemented as a group of classes. You might determine that Universe should be an interface.
I suspect you have determined what the Universe is in your application, and you want to figure out the best way to implement your design. That's fine but you need to explain what that design is in order for anyone to give you input about it.
dubwai,
::in order for anyone to give you input about it.
1M thanks for your kindness.
::Bascially. You don't start a design my saying........
1000% agreed. (See how generous I'm. I said One thousand, not one hundred :-D )
::I suspect you have determined what the Universe is in your application, and you want to figure out the best way to implement your design.
I suspect you: You sound like a Sherlock Holmes! (just for a laugh only.)
If you look at again my 1st post where I mentioned the link 'static versus singleton' you will see that I try to find the underlying reason that justify a Singleton or a Static class beside
the technical avantages that offer a Singleton from Design Pattern and OOP point of view. My goal is to search for other underlying reason that justify a Singleton or a Static class beside
the pure technical avantage that offer a Singleton from Design Pattern and OOP point of view. (which is very important.)
Just a side note only:
Os has offered his personal reason which is one among many possible reasons that other people can come up and justify it. And we don't have to agree to that view as long as your/ours are justified. And that's I meant but not well expressed; "either way depending on your design point of view imply there is more than one solution to a problem"
See Aug 21, 2003 11:33 AM where Os replied.
See post Aug 21, 2003 12:19 PM where I replied to Os's reason.
OK but the technical advantages of a Singleton over a static class or vice-versa depend on what you are doing with this class. I have already given the main differences between the two strategies and the main reason to use one of the other. If you are still confused you need to describe your design so that I can explain which I think is more appropriate in your situation.
Hi again,
As dubwai says, it really depends on what the Universe class consists of and how you use it. If it contains:
private Collection galaxies;
private double amountOfDarkMatter;
private Collection blackHoles;
private double radius;
private StarShip enterprise;
...
i.e. it is composed of other objects, then it is really an object itself, and should be treated as such (i.e. it should be a singleton). This also allows it to be passed around like any other object:
Collection thingsForEvilGeniusToDestroy = new HashSet();
thingsForEvilGeniusToDestroy.add( FlashGordon.getInstance() );
thingsForEvilGeniusToDestroy.add( new TeenPopStar() );
thingsForEvilGeniusToDestroy.add( Universe.getInstance() );
However, if it just provides services, and is not required to have any 'identity':
public double calculateGravity()
public void cutHair( Klingon klingon );
...
then it should probably be static.
I think this is one of those places where nothing beats experience when it comes to deciding which style to use. It is also possible for a class to implement both styles, with the static methods just forwarding the requests to a privately held singleton.
Ol.
0sa at 2007-7-14 22:26:40 >
Hi 0s, dubwai,
1.
::i.e. it is composed of other objects, then it is really an object itself, (plus example...)
::if it just provides services, and is not required to have any 'identity': (plus example...)
Great explaination. Very cool!. I like your distinction/differences. You should be a teacher. :-D
2.
::I think this is one of those places where nothing beats experience when it comes to deciding which style to use.
It is also possible for a class to implement both styles,
with the static methods just forwarding the requests to a privately held singleton.
This is a great lecture for me.
3.
::As dubwai says, it really depends on what the Universe class consists of and how you use it.
As for dubwai, should be a teacher as well. :-D
Again, 1M thanks to both of you.
I would make a universe an Object.
Making it an instanton means that you cannot possibly have more than 1 universe in a single "instance" of your application. I don't really know what you want to do with a universe, but personally I wouldn't make my universes singletons. For example you could have a program that can simulate universe where you can set different properties (object fields) of the universe (like gravity, number of stars etc...). If your universe would be a singleton you can only work with one simulation of a universe at a time, but perhaps you would like to have many universe simulation windows open that shows simulations of universes with different parameters at a time. (You can also think of a 3D graphics program where each opened 3D image has all of its objects in a "universe".)
> Hi,> > Personally, I'd make the universe a singleton. The> universe is an 'object', not a class, By the way: A class is an special object!GreetingsPara
Hi,
static methods and members are ment to describe the collectivity of the objects of a class. For instance the number of universes is a good canditate for a static member in the class universe. The reference(s) to the universe(s) is another example for a static member. Static methods would be (add(Universe newOne), remove(Universe sorry)).
All "regular" methods (do(), expand(), collaps()) should be non-static, because they refer to an object (a special universe) and not to the class of universes.
Disadvantage: If you need to have special kinds of universes (sub classes), static methods are bad, because they are not polymorph.
Greetings
Para
One word:
Parallel Universes.
If you believe that there is only one universe you are just wrong. Universes are not objects but threads. From time to time some ***** will invent a way to interact with another universe, which will cause deadlocks and all other nasty stuff. That's why large portions of the universe have been synchronized, that's what we physicists call dark matter.
QED
