From: Mike Lopke <reglopke@...>
Date: 2008-11-05T07:45:34+09:00
Subject: Re: Ruby's take on S.O.L.I.D.

Jeff Cohen wrote:
> On Nov 3, 2:38�pm, Mike Lopke <reglo...@cableone.net> wrote:
>> >> 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.
> 
> The LID (substitution, inteface granularity, dependency injection) are
> just non-issues for me with Ruby.  I enjoy duck-typing so much more
> than worrying about interface granularities, and I don't need to use
> dependency injection anymore (which I really only used to make things
> more testable, which I can do with Mocha nowadays anyway).
> 
> I'd be interested in other viewpoints on this, but I think SOLID is
> great advice only for statically-typed languages and isn't quite as
> important with a language like Ruby.
> 
> For me, the SOLID equivalent would go like this:
> 
> Single Responsibility per Class
> Drive your development with unit tests
> Have fun
> 
> ...but "SDH" isn't as easily pronounced as SOLID. :-)
> 
> Jeff
> 
> www.purpleworkshops.com

Thanks for the feedback. I was wondering specifically about the LID part 
and how important they were for a static vs duck type language. I've 
been out of Java for some time and by default now think like a dynamic 
language.

For example, the typical Liskov Substitution example you see in Java has 
the case where you have a Rectangle class and a derived Square class. 
The Rectangle has an independent width and height. They have to be the 
same for the Square. Somewhere in the example they do something like 
this:

Rectangle r = Rectangle.new( Square.new() );

Then they proceed to show that the methods for setting the width and 
height for a Rectangle, behave like a Square and you get unexpected 
results. While I understand the logic, I must confess this construct 
feels really odd from a Ruby mindset. I'm trying to remember why this is 
so important for statically typed language. Does it have to do with 
something like collections or another mechanism?

Mike
-- 
Posted via http://www.ruby-forum.com/.