Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Would you consider them Singletons?

 
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In one of my classes, the instructor stated that the Math and System classes are examples of the Singleton pattern. His definition was restricting a class so that at any time in the life of the system there can be only 0...1 instances of that class. Normally I have seen Singletons done with the private static final ClassName cn = new ClassName(); initializer, the private ClassName() constructor, and then an accessor method that always returns that one instance.
I'm curious if Math and System really could be considered to fall into this pattern, or are they just examples of utility/function classes?
Jason
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Math and System classes do not have a constructor at all. All methods are static. The run time does not create an insatnce of the class at all. I would not classify them as singletons.
Sanjay
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually they do have a constructor, it is just private so it is not visible beyond that class.
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Yes,as you said, singletons are mainly to restrict the number of instance to 0..1 at any given time. Where more than one instance does not make any sense.
Generally they are entity classes providing static or common information to other classes in the system.
No Math & System are not examples of Singletons.
All the methods in those classes are static methods.
Not even a single instance can be made of those classes (the constructors are private).
Math:
- all variables(two)and all the methods are static
public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;
- an empty private constructor
System:
- all variables and all the methods are static
- an empty private constructor
Thanks,
Prem
------------------
pondyprem@yahoo.com
 
Tiger Scott
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well yes it does have a private do nothing constructor- just to ensure the class can not be instantiated at all. This is just the technique to do it.
/**
* Don't let anyone instantiate this class.
*/
private Math() {}
HTH
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pondy - Thanks, that's basically my line of thought, also. With Singletons, you would actually be using the one object that is created, and the interfaces that the class provides. As you mentioned, you don't do this with Math and System. Since they are all static, you use the methods in the class, but NOT through an object. That's the distinction I was looking at, but I've been wrong before, so wanted to see what others thought
Sanjay - Yup, saying that a class doesn't have a constructor and saying they have no visible constructor are two completely different statements, even if the constructor doesn't do anything.
Jason

[This message has been edited by jason adam (edited November 13, 2001).]
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I agree they're not Singletons. One of the key things about singletons is that they can be extended (subclassed). Obviously you can't do that meaningfully with classes that only have static methods.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, if they are not sigletons, apart from using a private constructor can anybody suggest how you can restrict 0-1 instance at any give time? Will you need to do that programatically in the constructor?
Thanks
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't think of a way to restrict access to 1 instance without using the private constructor/public static accessor combination.
Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Sheriff
Posts: 6963
2
Eclipse IDE Debian Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just as a reminder, the Singleton pattern as expressed in GoF actually allows for any restricted number of instances, not just 1. Using purely static methods (as in Math) is at most a degenerate case of the pattern - as it can not be easily modified to allow a limit of two objects (for example).
As well as the "public static getInstance()" tecchnique, another popular way of making singletons is to use one of the Factory patterns. Code to an interface, use a Factory to produce the implementing object(s).
 
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Frank:
I cannot afford books but here is a link for singleton with limited number of instances
http://www.javaworld.com/javaworld/javaqa/2001-11/01-qa-1102-singleton.html?
Since 0 is also inside restricted/fixed a priori number it is inside singleton notion.
I do not agree with Frank:
I think that the term for System and Math classes is "helper", ie they may not be instantiated, inherited because their function is providing functions (functionalities), constants. And they may not be instantiated or killed, their function is to be omnipresent.
Therefore they are not to be changed (to permit 2 instances)?! Let me know how (by Email)
Hi, all.
I do not understand what do you mean by visibility of constructor. I look the code and it is pretty visible, to me. Strange people. It is just not accessible. Because constructor is visible but not accessible, it prevents altering, instantiation, etc. Has it been invisible you could just forget it, inherit the class, make your surgeries and violations
I have not used UML 3 yrs but it seems to me that in contrast to singleton there UML definitions for (class and object level) visibility and access. Or I am confusing with other language?
I would like to tell that singleton is just organizational/methodological/inter-language notion and there is no connection to Java's concretes. I do not remeber that I crossed thru any such term in UML, Java, C++, or Pascal. Just a pattern term. Generic and abstract, out of any real circumstance or environment.

[This message has been edited by G Vanin (edited November 14, 2001).]
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that the Singleton Pattern, like most patterns, is generic: it can be used by a number of programming languages. As for "visibility", my understanding is that in this context, the words visibility and accessibility are interchangeable. If an attribute in a class is private, for example, it could be said that this attribute is not "visible" outside of the class.
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They are not interchangeable http://www.javaworld.com/javaworld/javaqa/2001-04/04-qa-0427-subclass.html?
If a private constructor is not visible, it will not prevent inheriting, violating, i.e. cod change
[This message has been edited by G Vanin (edited November 14, 2001).]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In other words, private constructor is visible but not accessible. Had it been invisible, then it would not have prevented mutilations, sorry, violations of idea & coding
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Like Michael said, I was saying that a private constructor is not visible beyond the scope of the class. The article link you provided states just that:

Those private members and attributes are still in your subclasses. Your subclasses just cannot access them directly.


Try to compile the following code:
And tell me what error you get. Of course, being this does not compile (at least didn't for me, I'm using 1.4), that raises the question how do you extend a Singleton, if a Singletons constructor is private?
Jason

[This message has been edited by jason adam (edited November 14, 2001).]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jason,
I have written the text before PS without seeing your code (what you have added later and well I also already tried).
I am sorry I had given a link without looking in it.
This all depend on the point of view. Who (object of the same class, object of another class, programmer, same class [code], other class [code], compiler, run-time JVM) is looking and from where, how (the inheritance is not the only way of access and visibility). Default constructor just cannot be invisible because all of the participants know it is there.
First of all, any instantiation requires implicit (provided by whom, by compiler) or implicit (super) call to superclass´┐Ż constructor. Who does not know it? There is no sense of knowing by anybody except compiler, it is comiler error trying to extend a class with private default constructor.
I just wanted to underline general idea that visibility and access differ.
PS. Doesn't given by you citation contradict your code?
Really I would like to get to UML Glossary and book to see definitions. I do not have any and I really feel uneasy discussing what is forgotten by me for, at least, 3 years.
[This message has been edited by G Vanin (edited November 14, 2001).]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

how do you extend a Singleton, if a Singletons constructor is private?


Well - make the constructor protected?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kyle Brown:
Yes, I agree they're not Singletons. One of the key things about singletons is that they can be extended (subclassed). Obviously you can't do that meaningfully with classes that only have static methods.
Kyle


Another key thing is that the knowledge about the actual number of instances is encapsulated by the singleton class. Obviously you can't do this with the "static methods pattern", too.
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
Well - make the constructor protected?


Ok, besides the obvious
I thought that a private constructor was a "requirement" for the pattern to work, though. I guess just as long as only one object of that class (or whatever limit you want to put) is created, the access modifier doesn't matter.
Jason
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You hit upon something G that I think is causing our communication conflict. When I speak of visibility, I am talking about classes, period. I'm not concerned about what the compiler or JVM can see, because they can see everything. If they couldn't, that would be just down right silly. I don't care about what the programmer can see, because what a programmer reads in the source code doesn't really impact what the program is doing. I'm only concerned about how one class directly accesses members of another. In this regard, visibility and access ARE interchangeable.
Yes, you're right, the sample is a little contradictory, and I actually find the article contradicts itself, so my apologies on that. I've written JavaWorld and the author of the article for some clarification, I'll post it once/if I get a response.
In regards to the default constructor comments, if I follow what you are saying correctly, from the view point of the compiler, yes everything is visible. Again, I'm not looking at it from that view point. I think we are agreeing for the most part on this, just not getting our points across clearly That's what ya get from a multicultural website sometimes!!
Jason
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jason,
my last experience with differences between visibility and access is 3 yrs ago and it was in terms of application compatible with UML, i.e. in +- UML terms.
I prefer return now to UML (and not looking to Java) because:
1) UML is more common standard.
2)this forum is abouth UML
I consulted UML glossary and visibility is defined in terms of public, protected and private idioms. While access in terms of the semantical/syntactical "right".
In Java that right is class-level what means that any member/method of the object is visible by the object of the same class. ALWAYS. But it is just specific to Java.
Now, in terms of UML, only access differ.
I am sorry for confusion but somehow there is a need for common terminology and unfortunately Java is not good for common terms.
 
jason adam
Chicken Farmer ()
Posts: 1932
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The forum is about Object Oriented programming in general, patterns, refactoring, andUML, so to expect a standard in such a forum is wishful thinking. I've noticed that even within UML people tend to use their own notations and don't necessarily stick with what has been laid down. To come up with one standard for all languages to speak to would be an extremely difficult task, and then you'd have to deal with the fact that each individual programmer is going to bring their own ideas to that standard.
And of course, since this IS the Java Ranch, you're going to get a majority of people that speak Java vs. what C++ might use, etc. The most important thing is to focus not on syntax but on the underlying concepts. Of course, that is so much easier said than done.
Jason
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And we should also note that the initial question that started this thread was about the singleton pattern in Java. Also G's article wasn't about UML but rather about Java.
As to the article, although G claims that the article proves that "accesibility" and "visibility" are not interchangeable, the article uses them interchangeably! I get the impression that G is arguing simply for the sake of arguing. Once he realized that he was losing the argument he decides to switch to UML. Instead of being petty, I would suggest that G may wish to have a discussion. There are no winners in discussions at JavaRanch.

[This message has been edited by Marilyn deQueiroz (edited November 21, 2001).]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thomas,
earlier I already begged a pardon for citing a wrong article.
I remember that I read an article illustrating differences somewhere in javaworld site. So when I made a search in javaworld I just picked up the first reference and did not care spending time looking inside just because it was quite collateral issue to this thread while answering to the main point (and even that I do not consider that much useful for taking attention of others, sincerely)
I give up in that theme, accessibility vs visibility, are you happy?
That collateral theme gave me opportunity to revive interest in UML, look for a book in a shops, today (could not find any) and brought me to some definitions. It was useful
Except posting without reading carefully you just take time and not only mine without bringing anything to even collateral discussion.
[This message has been edited by G Vanin (edited November 15, 2001).]
[This message has been edited by G Vanin (edited November 15, 2001).]
[This message has been edited by Marilyn deQueiroz (edited November 21, 2001).]
 
Ranch Hand
Posts: 1246
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kyle Brown:
Yes, I agree they're not Singletons. One of the key things about singletons is that they can be extended (subclassed). Obviously you can't do that meaningfully with classes that only have static methods.
Kyle


Hi Kyle,
Why it is one of the key things about signletons is the they can e extended? I don't understand that, Can you explain a little more on that?

 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's take a for-instance on this one. Let's say that you have a singleton class that encapsulates obtaining database connections for your application, and that in it you implement your own database pooling.
Let's say that furthermore you want to be able to switch over to using the database pooling provided by a J2EE app server, but don't want to change other classes in your system.
If your singleton is implemented in instance methods, with a single static accessor to get to the singleton instance, no problem -- you can subclass your old class (say ConnectionPool) with a new class (J2EEConnectionPool) and the ONLY thing that has to change anywhere in your code are the lines where you obtain the singleton. In this way you can pick which clients use the old version and which use the new version, but only one line of code per client class changes.
If you used the Factory pattern to obtain the singleton (not using a static accessor method) then it's even easier -- just change the single line in the Factory that creates the singleton (to make the change globally), or add another factory method and change your code to call it on a client-by-client basis.
Of course, if if were me doing this I'd probably change my original singleton class to be abstract and then make two subclasses to implement the two different ways of pooling, but that's beside the point
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
 
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kyle,

I'd probably change my original singleton class to be abstract and then make two subclasses to implement the two different ways of pooling, but that's beside the point


What if your client application start instantiating both of your sub-classes? Won't it defeat the purpose of Singleton? Similarly what if your clients start instantiating the superSingleton class and SubSingleton class?
My understanding is, Apart from a private constructor, Singleton pattern has to have a final class as well.
-Ramesh
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ramesh Donnipadu:
What if your client application start instantiating both of your sub-classes? Won't it defeat the purpose of Singleton? Similarly what if your clients start instantiating the superSingleton class and SubSingleton class?


The client isn't responsible for instantiating the singleton and wouldn't need to know about the subclasses. It's the abstract base class that would decide which actual implementation to use, for example depending on configuration.
 
Ramesh Donnipadu
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The client isn't responsible for instantiating the singleton and wouldn't need to know about the subclasses. It's the abstract base class that would decide which actual implementation to use, for example depending on configuration.


I feel there is a difference between the clients needing to know something versus the clients can not do something. The later helps the prevention of accidental or wilful misuse of your class.
If you make your singleton a final class, your clients can not subclass it even if they want to. This is what Bruce Eckel advocates.
-Ramesh
[ May 08, 2002: Message edited by: Ramesh Donnipadu ]
[ May 08, 2002: Message edited by: Ramesh Donnipadu ]
 
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I am newbie to design patterns.
This is what I understand about singleton patterns after my professor explained it.
We can use Singleton pattern when there must be exactly one instance of a class and it must be accessible to clients from a well-known access point.
Singleton pattern - declares the unique instance of the class as a static variable, and defines a static method for clients to access the unique instance.

Now I am confused after reading some posts that Sigleton is not for exactly restricting 0 to 1 instances and about subclassing it, how can we extend a class that is singleton since it has private constructor?
Thanks,
Vanitha.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ramesh Donnipadu:
I feel there is a difference between the clients needing to know something versus the clients can not do something. The later helps the prevention of accidental or wilful misuse of your class.


Yes, there is a difference. But I am no fan of "defensive programming" - if someone wilfully misuses my class, I am fine, he just has to live with the consequences. I am not willing to clutter up my code just to defend against abuse.
Regarding accidental misuse of a class, I would first try to use forms of communication which don't reduce the agility of the code. For example I think that the use of the singleton pattern itself should communicate much about intended usage. Not to say that I wouldn't ever use the mechanisms you mentioned, but they are far from being my standard way.
[ May 13, 2002: Message edited by: Ilja Preuss ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic