From: Dean Wampler <deanwampler@...>
Date: 2008-11-05T08:35:42+09:00
Subject: Re: Ruby's take on S.O.L.I.D.

I actually blogged about a few of them on the OM blog a few months ago.

http://blog.objectmentor.com/articles/2008/09/06/the-liskov-substitution-principle-for-duck-typed-languages

http://blog.objectmentor.com/articles/2008/09/04/the-open-closed-principle-for-languages-with-open-classes

I need to blog about the others, for completeness.

I think if you take them at face value, they don't fit well, because
they seem too oriented towards statically-typed languages. However, if
you look at the underlying reasons for their existence and their
intentions, then you can adapt them to ruby. For example, I think the
Open/Closed Principle adapts nicely to open types, as I blogged.

For another example, this is true even for the Interface Segregation
Principle (ISP), despite the fact that Ruby doesn't have Java-style
interfaces, per se. What it has, of course, are informal interfaces
required by the "duck type" ;)

Hope this helps.

dean

On Tue, Nov 4, 2008 at 4:45 PM, Mike Lopke <reglopke@cableone.net> wrote:
>
> 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/.
>



--
Dean Wampler
http://www.objectmentor.com
http://www.polyglotprogramming.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org