I use both, judiciously, especially modifications of library classes.
Adding additional behavior is less risky than changing existing
behavior. That's all I ever do, in practical terms. As always,
different solutions are valid for different contexts.

Changing existing behavior may break other code that uses the same
classes, of course, so I would never do these changes without thorough
testing. I also wouldn't expect others to use any of my code that made
risky modifications.

My $0.02,

dean


On 6/5/06, Jeff Cohen <cohen.jeff / gmail.com> wrote:
> For most of my OO career (C++ for a long time, and then C#) I believed
> in the OCP very strongly.  It's supposedly the cornerstone of OOP,
> right?  I came across this article today which brought it mind again:
> http://www.ddj.com/blog/architectblog/archives/2006/05/open_closed_pri_1.html?cid=GS_blog_arnon
>
> But I remember my mind getting warped for a few hours when I was first
> learning Ruby last year and came across Rails code that extended
> existing classes so you could do this:
>
> 20.minutes.ago
>
> which I thought was just awesome.  Ruby lets me change anything I want
> about any class, it seemed, and it was a strange thing to me.
>
> Of course, I'm not worried about breaking existing code when it's just
> my own code, but I'm still violating the open closed principle by
> changing the Time class, right?  But I think this ability is one of the
> things that makes Ruby so great!
>
> So what gives?  Of course the idea of not changing behavior that clients
> depend on still holds - but that's something different, the concept of
> invariant intefaces.
>
> So maybe I've misunderstood the OCP all along?
>
> Or is just that we've come a long way since then?
>
> Jeff
>
> --
> Posted via http://www.ruby-forum.com/.
>
>


-- 
Dean Wampler
http://www.aspectassoc.com
http://www.aspectprogramming.com
http://www.contract4j.org