|
|
|
| "be consistent" | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
What do you mean that the method "normally does not return the sources"? That getInstance would be part of some proxy class? I don't see why this should be part of the Singleton pattern. It causes duplicity in classes that can be confusing.
The way I see it there are two reasons why you might want a singleton. The first is that you *need to have* only one instance of something, because it represents a unique entity that can only have one state; having multiple instances risks getting many of them out of date. The second is that you *only need* one, for example if the class doesn't really represent an ontic entity but does host some calulations (In that case you might be better off using class methods, but nevre mind that). In this case singletonhood inproves performance but isn't critical to design. In the first case, some people would like to make it explicit that a singleton is being used, and thus would prefer different coding styles when using it -- getInstance being the typical spelling. In the second case, there may be less incentive to rub in the singletonhood of the object. What I understand you to be saying is that you have some data or representational or proxy layer on top of the object. That's well enough, but it doesn't have much to do with singletons; you can have those on instantiable objects as well. In reply to Re^3: Singletons and Inheritance
by gaal
|
|