Confession: I never learned CS

Ruby
21

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.
+2

The language itself IS a pattern/structure that will determine and/or
enable patterns and structures!
Frameworks/libraries will tend to enforce patterns and structures.

Ruby is pretty open and fully object-oriented by design, while
enabling you to do procedural things to objects.

Rails is an example of a framework that really establishes and
enforces particular patterns and structures.

Simply by using code by others and using the language, you’ll find a
lot of these things quickly in Ruby.
Some things are well established patterns in C / C++ books (searching
& sorting algorithms) but they don’t always make sense as Ruby since
Ruby provides mechanisms that would be oh-so-much boiler plate code
in lower-level languages.

22

On Sep 27, 7:29 pm, MenTaLguY [email protected] wrote:

On Fri, 28 Sep 2007 06:31:47 +0900, “Rick DeNatale” [email protected] wrote:

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.

23

On 9/28/07, bpfurtado [email protected] wrote:

On Sep 27, 7:29 pm, MenTaLguY [email protected] wrote:

On Fri, 28 Sep 2007 06:31:47 +0900, “Rick DeNatale” [email protected] wrote:

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.

–
Rick DeNatale

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

24

On 9/28/07, Robert D. [email protected] wrote:

Patterns are all about picking paths due to the problem and situation
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:

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.

Rick DeNatale

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

25

On Oct 2, 12:55 pm, “Rick DeNatale” [email protected] wrote:

I didn’t say that. However, it does AFFECT how you design. But if you

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.