Prev: State of the union for Ruby CLI libraries?
Next: [ANN] Rack 1.2, a modular Ruby webserver interface
From: Michał Zając on 16 Jun 2010 14:48
W dniu 2010-06-15 01:06, Rein Henrichs pisze:

Let me put it this way: replace all of your
> pseudo-classes (these classes that don't instantiate and are used as
> singleton method holders) with this:
>
> YourClass = Object.new
>
> def YourClass.some_method
> ... do stuff ...
> end
>
> ... more ...
>
> This is functionally equivalent. Does this look like good Ruby code? Is
> this good OO design? If not, why not? The classes you're asking about
> aren't (functionally) classes at all: they're just objects like this
> one. You should object to them for the same reasons that you (may)
> object to the above.

I can't agree that using such classes is _always_ bad design. In well
designed systems there is a place for stateless classes too (of course
they are in minority). They main responsibility is not to encapsulate
data but encapsulate dependencies - for example AbstractSmtpClient which
encapsulates (wrapes) concrete SMTP client implementation. In Java this
kind of encapsulation is needed to unit test classes those use SMTP
communication. But what is more important to me is responsibility
separation (SRP) - actual business code doesn't have to create and
configure SMTP client - it just gets ready for use AbstractSmtpClient
object from outside (not necessary from heavy weight DI framework).

Back to your question - maybe it is _functionally_ equivalent of
defining methods inline one by one but it is not eqivalent in terms of
code readability (in my "psuedo-classes" I separated code that you have
mixed in one class) in this way we can treat every program (even written
in ruby) as "functionally equivalent" of assembler or I have
misunderstood your example :D

>
> Also, Ruby has far better mechanisms than dependency injection. So much
> so, in fact, that Rails core member and creator of two different Ruby
> dep. injection libraries, Jamis Buck, recently gave a great talk about
> why you don't need dependency injection in Ruby. Summary is here, and is
> a good read if you're coming from heavy, "enterprisey" languages like
> Java: http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming.

I never treat DI and automatic DI frameworks as the same thing - and I
repeat it to every programmer I am working with :) Due to better
language mechanisms (open classes) in ruby we can make dependency
injection as described in article. What I like less is mixing business
code and collaborators construction (new calls) in one physical code unit.

--
Best regards

From: Rein Henrichs on 16 Jun 2010 17:58
On 2010-06-16 11:48:32 -0700, Michał Zając said:

> W dniu 2010-06-15 01:06, Rein Henrichs pisze:
>
> Let me put it this way: replace all of your
>> pseudo-classes (these classes that don't instantiate and are used as
>> singleton method holders) with this:
>>
>> YourClass = Object.new
>>
>> def YourClass.some_method
>> ... do stuff ...
>> end
>>
>> ... more ...
>>
>> This is functionally equivalent. Does this look like good Ruby code? Is
>> this good OO design? If not, why not? The classes you're asking about
>> aren't (functionally) classes at all: they're just objects like this
>> one. You should object to them for the same reasons that you (may)
>> object to the above.
>
> I can't agree that using such classes is _always_ bad design. In well
> designed systems there is a place for stateless classes too (of course
> they are in minority). They main responsibility is not to encapsulate
> data but encapsulate dependencies - for example AbstractSmtpClient
> which encapsulates (wrapes) concrete SMTP client implementation. In
> Java this kind of encapsulation is needed to unit test classes those
> use SMTP communication. But what is more important to me is
> responsibility separation (SRP) - actual business code doesn't have to
> create and configure SMTP client - it just gets ready for use
> AbstractSmtpClient object from outside (not necessary from heavy weight
> DI framework).
>
> Back to your question - maybe it is _functionally_ equivalent of
> defining methods inline one by one but it is not eqivalent in terms of
> code readability (in my "psuedo-classes" I separated code that you have
> mixed in one class) in this way we can treat every program (even
> written in ruby) as "functionally equivalent" of assembler or I have
> misunderstood your example :D
>
>>
>> Also, Ruby has far better mechanisms than dependency injection. So much
>> so, in fact, that Rails core member and creator of two different Ruby
>> dep. injection libraries, Jamis Buck, recently gave a great talk about
>> why you don't need dependency injection in Ruby. Summary is here, and is
>> a good read if you're coming from heavy, "enterprisey" languages like
>> Java: http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming.
>
> I never treat DI and automatic DI frameworks as the same thing - and I
> repeat it to every programmer I am working with :) Due to better
> language mechanisms (open classes) in ruby we can make dependency
> injection as described in article. What I like less is mixing business
> code and collaborators construction (new calls) in one physical code
> unit.

I would prefer that you use modules for "stateless classes" that you
don't initialize. Modules are semantically for use in both "mixins" and
namespacing, and the namespacing here is an appropriate use. They also
don't share the semantic baggage that classes do (initialization) for
this use.
--
Rein Henrichs
http://puppetlabs.com
http://reinh.com

First  |  Prev  | 
Pages: 1 2
Prev: State of the union for Ruby CLI libraries?
Next: [ANN] Rack 1.2, a modular Ruby webserver interface