From: Ken Bloom <kbloom@...>
Date: 2008-11-10T00:37:46+09:00
Subject: Re: Ruby's take on S.O.L.I.D.

On Mon, 03 Nov 2008 16:29:54 -0500, Jeff wrote:

> On Nov 3, 2:38 pm, Mike Lopke <reglo...@cableone.net> wrote:
>> Stefan Rusterholz wrote:
>> > Mike Lopke wrote:
>> >> I'm curious about everyone's take on Bob Martin's S.O.L.I.D. design
>> >> principles. They seem to be getting a lot of traction with
>> >> statically typed languages such as C# and Java but I haven't heard
>> >> much buzz about it in the Ruby community.
>>
>> >> Any thoughts on how duck typing impacts the usefulness or necessity
>> >> of these design principles? For instance, I don't really hear much
>> >> regarding Liskov's Substitution Principle around Ruby programmers
>> >> and am interested in opinions as to why.
> 
> I was a SOLID developer in my C# days, but I don't feel it applies as
> well to dynamic languages like Ruby.
> 
> The S, I still agree with: single responsibility per class.
> 
> The O is something I'm on the fence about.  Ruby allows you to open
> classes and modify them, and I've seen how valuable this is when you
> know what you're doing.

One could espouse a design school in Ruby that used open classes to 
implement O, with rules such as "don't override existing methods when 
reopening a class, only add new ones". But Ruby as a language doesn't 
enforce this, and there are other kinds of changes that one could do for 
O that are actually quite complicated in terms of coding. For example, in 
my SqlStatement gem, I monkeypatch DBI to accept an SQL statement object 
as a query. It's probably an extension, but the facilities needed to do 
it look a lot like modification.

I think Groovy's categories and optional type specifications make this 
are constructs that would make O easier to enforce in a language.

But from what I see, the OpenClosedPrinciple was about refactorings, and 
not just about class extension. And in this sense, it sucks, because you 
can only implement the OpenClosedPrinciple if you have a perfect crystal 
ball about what you'll need in the future. (See http://c2.com/cgi/wiki?
OpenClosedPrinciple which points out that the Xtreme Programming 
principle of YouArentGonnaNeedIt is in total conflict, since that 
recommends avoiding the crystal ball completely.)

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/