Re: Singletons and Inheritance

First, Perl doesn't distinguish between names like "new" and "getInstance", so there's no language reason to prefer one.

If your client code has a design reason to know it's dealing with a singleton, you might have a stylistic incentive to use different names, otherwise, make it transparent.

The most elegant way I know of applying singletonhood to a class (if you don't mind introducing new tech) is with the Aspect module. All your code remains the same; you just say

  use Aspect::Singleton;

  aspect Singleton => 'Foo::new';
[download]

at the top of your class, and that's it.

Comment on Re: Singletons and Inheritance Download Code

Replies are listed 'Best First'.
Re^2: Singletons and Inheritance by PerlingTheUK (Hermit) on Jul 20, 2004 at 12:53 UTC
For me a getInstance method would not be part of the class itself but of the access class, that is basically registering with a first object of any kind whenever one is created and then returns either the registered object or if not yet creates a new one. This method normally does not return the sources but effectivley the data and therefor can for reduce the amount of data to what is required.	[reply]
Re^3: Singletons and Inheritance by gaal (Parson) on Jul 20, 2004 at 13:22 UTC
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.	[reply]