[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Singleton or full static class

Lolz Llolz

8/15/2007 4:01:00 PM

In other languages I'm using the singleton pattern when I need a
globally accessible object. But in Ruby so much is an object or behaces
like an object (or can be treated as an object) I'm not sure if I should
use the singleton pattern or make all methods to class methods and use
class variables.
What is the best practise in ruby?





Turing.
--
Posted via http://www.ruby-....
3 Answers

David A. Black

8/15/2007 4:14:00 PM

0

Gregory Seidman

8/15/2007 4:39:00 PM

0

On Thu, Aug 16, 2007 at 01:00:51AM +0900, Frank Meyer wrote:
> In other languages I'm using the singleton pattern when I need a
> globally accessible object. But in Ruby so much is an object or behaces
> like an object (or can be treated as an object) I'm not sure if I should
> use the singleton pattern or make all methods to class methods and use
> class variables.

The Singleton pattern is usually a design mistake anyway. See
http://www.adrianmccarthy.com/... for a good explanation. That
said...

> What is the best practise in ruby?

...there is a good way of dealing with such things in Ruby. Consider a
situation in which you think you need a singleton. What you really need is
a handle to some object on which you can call a method (arguably you just
need the method, but if there are enough of them then it pollutes the
global namespace, so let's assume you need an object). We'll call the
object foo_handler:

module Kernel
def foo_handler
::Kernel.foo_handler
end
def self.foo_handler
@foo_handler ||= FooHandler.new
end
end

You now have a (lazy-loading) singleton, which is stored in the Kernel
object (i.e. the object representing the Kernel module). Any time you need
access to it, you call foo_handler (in whatever context). Of course, if and
when it should no longer be a singleton you can change the implementation
of the method in Kernel without disrupting the rest of your code.

You can also omit the first method entirely and simply call
::Kernel.foo_handler explicitly, which gives you the same flexibility
without polluting the global namespace at all. Furthermore, using Kernel is
only an example; there is nothing special about a method on the Kernel
object that wouldn't work just as well as a method on some other constant.
After all, constant names are nothing more than a directory service, in the
same way that a filesystem can be thought of as a database.

> Turing.
--Greg

Robert Klemme

8/15/2007 7:20:00 PM

0

On 15.08.2007 18:38, Gregory Seidman wrote:
> On Thu, Aug 16, 2007 at 01:00:51AM +0900, Frank Meyer wrote:
>> In other languages I'm using the singleton pattern when I need a
>> globally accessible object. But in Ruby so much is an object or behaces
>> like an object (or can be treated as an object) I'm not sure if I should
>> use the singleton pattern or make all methods to class methods and use
>> class variables.
>
> The Singleton pattern is usually a design mistake anyway. See
> http://www.adrianmccarthy.com/... for a good explanation. That
> said...

I find that article is not a good source on the usefulness (or
harmfulness for that matter) of the singleton pattern. Using completely
unrelated items like the presence of multiple windows, servers etc. as
argument against the singleton pattern is - to say the least - a bit
strange and far from convincing.

There are numerous cases where you really just need a single instance
(stateless classes like comparators in Java for example). And the
singleton pattern explicitly deals with the fact that at some point in
time there may be multiple instances needed. And the fix can be as easy
as returning a new created instance instead of a constant.

Don't get me wrong, I am not religious about using this pattern. But if
something is discounted I expect at least sound reasoning.

>> What is the best practise in ruby?
>
> ..there is a good way of dealing with such things in Ruby. Consider a
> situation in which you think you need a singleton. What you really need is
> a handle to some object on which you can call a method (arguably you just
> need the method, but if there are enough of them then it pollutes the
> global namespace, so let's assume you need an object). We'll call the
> object foo_handler:
>
> module Kernel
> def foo_handler
> ::Kernel.foo_handler
> end
> def self.foo_handler
> @foo_handler ||= FooHandler.new
> end
> end
>
> You now have a (lazy-loading) singleton, which is stored in the Kernel
> object (i.e. the object representing the Kernel module). Any time you need
> access to it, you call foo_handler (in whatever context). Of course, if and
> when it should no longer be a singleton you can change the implementation
> of the method in Kernel without disrupting the rest of your code.

You just presented an implementation of the singleton pattern although
you place the accessor in a different class.

> You can also omit the first method entirely and simply call
> ::Kernel.foo_handler explicitly, which gives you the same flexibility
> without polluting the global namespace at all. Furthermore, using Kernel is
> only an example; there is nothing special about a method on the Kernel
> object that wouldn't work just as well as a method on some other constant.
> After all, constant names are nothing more than a directory service, in the
> same way that a filesystem can be thought of as a database.

I'd still prefer to keep this outside of Kernel if only to not stuff too
much into this module.

Regards

robert