Comments on: Class Methods http://www.klankboomklang.com/2007/10/19/class-methods/ Ruby and otherwise by Patrick Farley Wed, 08 Sep 2010 20:31:21 +0000 http://wordpress.org/?v=2.2.3 By: pfarley http://www.klankboomklang.com/2007/10/19/class-methods/#comment-138 pfarley Tue, 30 Oct 2007 04:05:27 +0000 http://www.klankboomklang.com/2007/10/19/class-methods/#comment-138 Hi Rick. Sorry it took a while to get back to you on this and thanks for the comment. It's an interesting point about managing the pool through new. I also cringe when I see GoF patterns copied verbatim into Ruby as if the "best" C++ solutions are the "best" Ruby solutions. That said, I think encapsulation veers uncomfortably close to misleading when a method called new does not actually return something that is new. The nice thing about "instance" or similar is that it's not promising you anything... maybe it's new, maybe it's from a pool, the only thing it suggests is that it is an instance of what you asked for. Hi Rick. Sorry it took a while to get back to you on this and thanks for the comment. It’s an interesting point about managing the pool through new. I also cringe when I see GoF patterns copied verbatim into Ruby as if the “best” C++ solutions are the “best” Ruby solutions. That said, I think encapsulation veers uncomfortably close to misleading when a method called new does not actually return something that is new. The nice thing about “instance” or similar is that it’s not promising you anything… maybe it’s new, maybe it’s from a pool, the only thing it suggests is that it is an instance of what you asked for.

]]> By: Rick Bradley http://www.klankboomklang.com/2007/10/19/class-methods/#comment-108 Rick Bradley Sat, 20 Oct 2007 19:05:23 +0000 http://www.klankboomklang.com/2007/10/19/class-methods/#comment-108 Patrick, Thanks for a very interesting read. I've often wondered why Ruby programmers who feel the need to use the Singleton (or Multiton, for that matter) patterns, don't simply change Foo.new to check a pool (@@pool), and for new objects call obj = Foo.allocate, and obj.initialize(args), pushing obj into @@pool, and returning obj. BDD-wise the behavior we want isn't usually of concern to the caller, but it is of concern to the Foo class. It's a creation-time behavior so it is definitely in the realm of the constructor. Unlike Java, .new is a class method rather than an operator. Just take over .new and implement the Singleton behavior there where it belongs. Why should client code have to call Foo.instance, e.g., and be aware of something that should be encapsulated in Foo. If the Singleton behavior needs to change, the .new method changes (or the override is simply taken out), and no client code has to be touched. I wonder if not taking advantage of Ruby in this way is just a too-literal reading of the popular Java implementation of GoF patterns carried along in a "Cargo Cult" manner. Best, Rick Patrick,
Thanks for a very interesting read.

I’ve often wondered why Ruby programmers who feel the need to use the Singleton (or Multiton, for that matter) patterns, don’t simply change Foo.new to check a pool (@@pool), and for new objects call obj = Foo.allocate, and obj.initialize(args), pushing obj into @@pool, and returning obj.

BDD-wise the behavior we want isn’t usually of concern to the caller, but it is of concern to the Foo class. It’s a creation-time behavior so it is definitely in the realm of the constructor. Unlike Java, .new is a class method rather than an operator. Just take over .new and implement the Singleton behavior there where it belongs.

Why should client code have to call Foo.instance, e.g., and be aware of something that should be encapsulated in Foo. If the Singleton behavior needs to change, the .new method changes (or the override is simply taken out), and no client code has to be touched.

I wonder if not taking advantage of Ruby in this way is just a too-literal reading of the popular Java implementation of GoF patterns carried along in a “Cargo Cult” manner.

Best,
Rick

]]>