Confession: I never learned CS

The book's correct title is "Smalltalk Best Practice Patterns", and I
would like to second the recommendation. Gianni Jacklone turned me
onto it a couple of years ago, and I really found it helpful.

···

On 9/28/07, Robert Dober <robert.dober@gmail.com> wrote:

On 9/27/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
<snip>
> I've got to agree here. I am/was friends with all four of the GOF and
> I hope that the three survivors won't be offended, but it's really a
> C++ book, and I fear that it has done as much harm as good for those
> trying to apply it to languages with less draconian (or is it baroque)
> design. Although Ralph put in some Smalltalk references they were
> mostly in the way of commentary when they were trying to do similar
> things in C++.
>
> Patterns are all about picking paths due to the problem and situation
> at hand, and for better or worse, the programming language is a big
> part of the situation at hand. Most of the GOF book deals with the
> issues raised by statically typed oo languages, and aren't as portable
> as one might think.
>
I know I might be off a little bit, but I'd rather recommend a book of
a different friend of your's "Smalltalk Best Practices" by Kent Beck.
I know it is not about Design Patterns but Micro Patterns, I know it
is not about Ruby but about Smalltalk.
Anyway Kent calls Ruby Smalltalk in disguise for some reasons, I am of
course referring to the "Smalltalk beating Java and being called Ruby"
saying.

Honestly I am only through the half of the book but there is just no
item so far I would not apply to Ruby.

This book is a must read anyway, gotta read *all* of his books :wink:

> Most of the GOF book deals with the issues raised by statically
> typed oo languages, and aren't as portable as one might think.

You couldn't be more wrong, being statically typed does not interfere
in the runtime messages exchange between your objects.

Design Pattern or better saying Object Oriented Modeling is just about
how to better model the comunications of your objects in order to get
more *reusable* and *maintainable* code.

Those OO techniques are highly valid for Java, C++, Ruby or Python
world.

···

On Sep 27, 7:29 pm, MenTaLguY <men...@rydia.net> wrote:

On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

I'd submit the issues have more to do with the lack of "nice"
higher-order functions than they do with object orientation or
static typing.

For instance: the Visitor pattern suddenly becomes trivial when
you have HoFs for traversal (Enumerable#each, anyone?).

-mental

I recently re-read this book, it's certainly a classic.

I discussed it with Kent a few months back, and asked if he'd ever
thought about doing a Ruby version, he said that he would like to but
the book market just didn't pay enough to make it worthwhile. The
real payoff in writing books for the technical market is the fame, and
Kent is probably more than famous enough for his needs.

On the other hand, I can't completely agree about it being 100%
applicable to Ruby.

As I've said before, programming patterns, best used, are selected in
a world of tensions and pressures generated by the requirements and
the languages and tools.

If you look closely at Smalltalk Best Practice Patterns, many are
specific to Smalltalk. Things like the patterns of how to construct
Smalltalk objects don't really apply to Ruby. Patterns relating to
instance state are affected by the differences between Smalltalk in
which instance variables are declared in classes with slots allocated,
and Ruby in which instance variables are dynamically acquired. Ruby
instance variables are actually an example of the Variable State
pattern which Kent, rightly, recommends using sparingly in Smalltalk.

Many of Kent's patterns are related to interacting well with the
Smalltalk IDE, i.e. doing things which work with the IDE to make it
easier to read the code and find the code you need to read.

And most of the chapter on Collection patterns isn't applicable
directly to Ruby, although I would encourage Rubyists to get some
background on Smalltalk collections.

Maybe more on this in my blog.

···

On 9/28/07, Robert Dober <robert.dober@gmail.com> wrote:

On 9/27/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
<snip>
> I've got to agree here. I am/was friends with all four of the GOF and
> I hope that the three survivors won't be offended, but it's really a
> C++ book, and I fear that it has done as much harm as good for those
> trying to apply it to languages with less draconian (or is it baroque)
> design. Although Ralph put in some Smalltalk references they were
> mostly in the way of commentary when they were trying to do similar
> things in C++.
>
> Patterns are all about picking paths due to the problem and situation
> at hand, and for better or worse, the programming language is a big
> part of the situation at hand. Most of the GOF book deals with the
> issues raised by statically typed oo languages, and aren't as portable
> as one might think.
>
I know I might be off a little bit, but I'd rather recommend a book of
a different friend of your's "Smalltalk Best Practices" by Kent Beck.
I know it is not about Design Patterns but Micro Patterns, I know it
is not about Ruby but about Smalltalk.
Anyway Kent calls Ruby Smalltalk in disguise for some reasons, I am of
course referring to the "Smalltalk beating Java and being called Ruby"
saying.

Honestly I am only through the half of the book but there is just no
item so far I would not apply to Ruby.

This book is a must read anyway, gotta read *all* of his books :wink:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

> > Most of the GOF book deals with the issues raised by statically
> > typed oo languages, and aren't as portable as one might think.

You couldn't be more wrong, being statically typed does not interfere
in the runtime messages exchange between your objects.

I didn't say that. However, it does AFFECT how you design. But if you
really look at GOF most of the patterns are tied up in technical
aspects of declaring interfaces, something which is crucial in C++ or
Java.

Although you can adapt some of the GOF patterns to languages like Ruby
or Smalltalk, they really do come primarily from the C++ school,
albeit many of them adapted Smalltalk practices. One of the reasons
that Smalltalk examples are rare in the book is because the Smalltalk
implementations of the ideas being expressed really didn't fit the
patterns as they are described.

Design Pattern or better saying Object Oriented Modeling is just about
how to better model the comunications of your objects in order to get
more *reusable* and *maintainable* code.

Those OO techniques are highly valid for Java, C++, Ruby or Python
world.

You get good code by working with the characteristics of your language
and tools. Many of the techniques in the GOF book are far more
applicable to Java and C++ than Ruby, Smalltalk or Python.

At an abstract level, the GOF book's biggest contribution was in
providing a common vocabulary for a certain set of patterns, and for
those using C++ and/or Java it gives good implementation advice.
However I maintain my position that those who look at it as a language
independent implementation cookbook aren't using it well.

···

On 9/28/07, bpfurtado <bpfurtado@gmail.com> wrote:

On Sep 27, 7:29 pm, MenTaLguY <men...@rydia.net> wrote:
> On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

> > > Most of the GOF book deals with the issues raised by statically
> > > typed oo languages, and aren't as portable as one might think.

> You couldn't be more wrong, being statically typed does not interfere
> in the runtime messages exchange between your objects.

I didn't say that. However, it does AFFECT how you design. But if you
really look at GOF most of the patterns are tied up in technical
aspects of declaring interfaces, something which is crucial in C++ or
Java.

Although you can adapt some of the GOF patterns to languages like Ruby
or Smalltalk, they really do come primarily from the C++ school,
albeit many of them adapted Smalltalk practices. One of the reasons
that Smalltalk examples are rare in the book is because the Smalltalk
implementations of the ideas being expressed really didn't fit the
patterns as they are described.

> Design Pattern or better saying Object Oriented Modeling is just about
> how to better model the comunications of your objects in order to get
> more *reusable* and *maintainable* code.

> Those OO techniques are highly valid for Java, C++, Ruby or Python
> world.

You get good code by working with the characteristics of your language
and tools. Many of the techniques in the GOF book are far more
applicable to Java and C++ than Ruby, Smalltalk or Python.

At an abstract level, the GOF book's biggest contribution was in
providing a common vocabulary for a certain set of patterns, and for
those using C++ and/or Java it gives good implementation advice.

However I maintain my position that those who look at it as a language
independent implementation cookbook aren't using it well.

In that point I totally agree with you, you gotta learn more than the
syntax from one language to another.

Regarding Design Patterns, they will apply equally well with your OO
language regardless they force you to statically declare the types of
your variables, having duck typing or not [http://en.wikipedia.org/
wiki/Duck_typing].

There will be always a room for Visitor implementations on compilers
written in any language, always a room for Observer/Observable in
event oriented APIs, Template methods, etc. In Python, Ruby, Java,
etc.

There's a way to think in each language/platform but Design Patterns
are well applied to any OO design. You can look for than on good
frameworks or APIs in Python or Ruby.

···

On Oct 2, 12:55 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

On 9/28/07, bpfurtado <bpfurt...@gmail.com> wrote:
> On Sep 27, 7:29 pm, MenTaLguY <men...@rydia.net> wrote:
> > On Fri, 28 Sep 2007 06:31:47 +0900, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

--
Rick DeNatale

My blog on Rubyhttp://talklikeaduck.denhaven2.com/