Forum: Ruby Make a revised version of design patterns in ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
288733e11db1c6dbbf50871d2c6738c6?d=identicon&s=25 Uncutstone Wu (uncutstone)
on 2006-05-18 09:43
Ruby is highly dynamic and extensible. Ruby is duck typed. Interface
which is pervasive in Java is hard to see in Ruby. Thing changes. Many
Gangof4 design patterns handle limitations of static languages like java
and C++. So I think in Ruby, some design patterns become trivial or
irrelevent , some can be simplified a lot.
Ruby is a fully object-oriented language. If we talk about OO, we surely
concerns about design patterns.I think many of us want to see what
happens to design patterns in ruby.
And I think the best way is to check the G4 design patterns one by one
to see which one can be simplified , which one becomes trivial , or some
new ones can be introduced.
Actually, I just think it is a good idea and I am not qualified to do
that. But I think this community can do it. Anyone checks a pattern,
then post his result here. We will soon get a revised version of design
patterns in ruby.  Itâ??s attractive. I hope you are instrested , your
attendance is highly appeciated.

And I will post one first, an abstract factory example, which can be
simplified a lot as following. You can see, no inheritance tree needed.

class MacWindow
	def whoami; puts "A Mac window";end
end
class MotifWindow
	def whoami; puts "A Motif window";end
end
class MacScrollbar
	def whoami; puts "A Mac Scrollbar";end
end
class MotifScrollbar
	def whoami; puts "A Motif scrollbar";end
end
class WidgetFactory
	def initialize(winCls, scrollBarCls)
		@winCls = winCls
		@scrollBarCls = scrollBarCls
	end
	def makeWindow
		@winCls.new
	end
	def makeScrollBar
		@scrollBarCls.new
	end
end

def testWidgetFactory
	f = WidgetFactory.new(MotifWindow, MotifScrollbar)
	aWin = f.makeWindow
	aScrollBar = f.makeScrollBar
	aWin.whoami
	aScrollBar.whoami
	f = WidgetFactory.new(MacWindow, MacScrollbar)
	aWin = f.makeWindow
	aScrollBar = f.makeScrollBar
	aWin.whoami
	aScrollBar.whoami
end

testWidgetFactory

result:

A Motif window
A Motif scrollbar
A Mac window
A Mac Scrollbar

Best regards,

uncutstone
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-18 14:03
(Received via mailing list)
2006/5/18, uncutstone wu <uncutstone@sina.com>:
> Ruby is highly dynamic and extensible. Ruby is duck typed. Interface
> which is pervasive in Java is hard to see in Ruby. Thing changes. Many
> Gangof4 design patterns handle limitations of static languages like java
> and C++. So I think in Ruby, some design patterns become trivial or
> irrelevent , some can be simplified a lot.
> Ruby is a fully object-oriented language. If we talk about OO, we surely
> concerns about design patterns.I think many of us want to see what
> happens to design patterns in ruby.

That might be an interesting thing to do.

> simplified a lot as following. You can see, no inheritance tree needed.
<snip/>

IMHO you don't even need a separate class.  Every object that
implements #new is a factory, especially every class object is.  So
storing an object somewhere and requiring that it implements new
without args is enough.

Regards

robert
288733e11db1c6dbbf50871d2c6738c6?d=identicon&s=25 Uncutstone Wu (uncutstone)
on 2006-05-18 17:43
Robert Klemme wrote:
> 2006/5/18, uncutstone wu <uncutstone@sina.com>:
>> Ruby is highly dynamic and extensible. Ruby is duck typed. Interface
>> which is pervasive in Java is hard to see in Ruby. Thing changes. Many
>> Gangof4 design patterns handle limitations of static languages like java
>> and C++. So I think in Ruby, some design patterns become trivial or
>> irrelevent , some can be simplified a lot.
>> Ruby is a fully object-oriented language. If we talk about OO, we surely
>> concerns about design patterns.I think many of us want to see what
>> happens to design patterns in ruby.
>
> That might be an interesting thing to do.
>
>> simplified a lot as following. You can see, no inheritance tree needed.
> <snip/>
>
> IMHO you don't even need a separate class.  Every object that
> implements #new is a factory, especially every class object is.  So
> storing an object somewhere and requiring that it implements new
> without args is enough.
>

Yes, you are right. Class WidegetFactory is unnecessary. So an simpler
version is:
class MacWindow
	def whoami; puts "A Mac window";end
end
class MotifWindow
	def whoami; puts "A Motif window";end
end

def testAbstractFactory
	aWinFactory = MotifWindow
	aWin = aWinFactory.new
	aWin.whoami
end

testAbstractFactory

result:
A Motif window

In fact, as the code shows, in ruby, abstract factory pattern
disappears, since a pattern always means a group of collaborative
classes or objects. I really think ruby is a magic language.

Best regards,

uncutstone
9dfe8c734b0f9b37a4e218425c0a2138?d=identicon&s=25 gene.tani@gmail.com (Guest)
on 2006-05-18 17:53
(Received via mailing list)
uncutstone wu wrote:

> Actually, I just think it is a good idea and I am not qualified to do
> that. But I think this community can do it. Anyone checks a pattern,
> then post his result here. We will soon get a revised version of design
> patterns in ruby.  It's attractive. I hope you are instrested , your
> attendance is highly appeciated.
>

http://www.rubygarden.org/ruby?ExampleDesignPatternsInRuby
http://raa.ruby-lang.org/cat.rhtml?category_major=...
288733e11db1c6dbbf50871d2c6738c6?d=identicon&s=25 Uncutstone Wu (uncutstone)
on 2006-05-18 19:15
gene.tani@gmail.com wrote:
> uncutstone wu wrote:
>
>> Actually, I just think it is a good idea and I am not qualified to do
>> that. But I think this community can do it. Anyone checks a pattern,
>> then post his result here. We will soon get a revised version of design
>> patterns in ruby.  It's attractive. I hope you are instrested , your
>> attendance is highly appeciated.
>>
>
> http://www.rubygarden.org/ruby?ExampleDesignPatternsInRuby
> 
http://raa.ruby-lang.org/cat.rhtml?>category_major...

Acctually, I did took a look at ExampleDesignPatternsInRuby
 before. But after read the first one , abstract factory, I am skeptical
of its quality.

I quoted the code and the explanation the author made below and I will
explain my view.

>class Foo; end
>class Bar; end
>
># Here is the use of the Abstract Factory pattern
>
>def create_something( factory )
>new_object = factory.new
>puts "created a new #{new_object.class} with a factory"
>end
># Here we select a factory to use
>create_something( Foo )
>create_something( Bar )
>Running the code above results in the output:
>created a Foo with a factory
>created a Bar with a factory
>
>
>Q: Ummm. Seems to me that you're specifying the concrete class name here: 
create_something(Foo) and
>create_something(Bar). My understanding of Abstract Factory is that there's an additional 
level of I>ndirection involved.
>A: The create_something method is creating objects through an abstract interface and does 
not have >knowledge of concrete types.
>The code at the top level is selecting which factory object will be used by 
create_something. There always >needs to be some part of
>the code that creates factories, and that part needs knowledge of concrete types. The use 
of the >Abstract Factory method is to shield
>the rest of the code from that knowledge.


I fully donâ??t agree with the authorâ??s opinion.  I think what abstract
factory does is to shield clients who need create object from the
objectâ??s concrete type, but not to shield the abstract factory itself
from concrete type.
Acctually ,abstract factory will have the knowledge of the concrete type
and shield the client of abstract factory from the concrete type .

But what the code does is opposite. The abstract factory(here is
create_something) doesâ??t know concrete type, and the client will give
that info to it every time the client need a object. Itâ??s toally
misunderstanding of abstract factory.

Since the first pattern example in the article is really bad , I am
skeptical of its quality. So I think we need redo the work. That is why
I post this message.

Best regards,

uncutstone
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-18 19:46
uncutstone wu wrote:
> I fully donâ??t agree with the authorâ??s opinion.  I think what abstract
> factory does is to shield clients who need create object from the
> objectâ??s concrete type, but not to shield the abstract factory itself
> from concrete type.
> Acctually ,abstract factory will have the knowledge of the concrete type
> and shield the client of abstract factory from the concrete type .
>
> But what the code does is opposite. The abstract factory(here is
> create_something) doesâ??t know concrete type, and the client will give
> that info to it every time the client need a object. Itâ??s toally
> misunderstanding of abstract factory.

The way I understood the examle is that "create_something" IS the
client.  It gets passed the abstract factory (parameter named factory)
and is actually shielded from the concrete class of the factory.  The
example is confusing in that the client immediately passes the created
object to the calling context (which is where the concrete factory is
know), but the comments seem to make it clear the intention of the
author.

My problem with the example is that it doesn't solve the same problem as
the classical GOF Abstract Factory pattern.  In the GOF pattern, the
abstract factory is able to build a set of related classes, not just a
single class.  This is used (for example) in windowing systems where you
want to be able to create a set of related widgets (e.g. GtkButton and
GtkScrollbar, or QtButton and QtScrollbar).  The example completes
misses that part of the pattern.

-- Jim Weirich
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-18 19:52
Jim Weirich wrote:
> [...] The
> example is confusing in that the client immediately passes the created
> object to the calling context [...]

Oops, Let me correct this.  I see that the create_something does not
actually return the created object.  So the confusion is not that it
returns something (which it does not), but only that the name
"create_something" fooled me into thinking it _did_ return something.  I
didn't read it closely enough.

On my second point about creating multiple types, I see the Maze example
does cover that aspect of abstract factories ... at least implicitly.

--
-- Jim Weirich
288733e11db1c6dbbf50871d2c6738c6?d=identicon&s=25 Uncutstone Wu (uncutstone)
on 2006-05-19 05:25
Jim Weirich wrote:
> The way I understood the examle is that "create_something" IS the
> client.  It gets passed the abstract factory (parameter named factory)
> and is actually shielded from the concrete class of the factory.  The
> example is confusing in that the client immediately passes the created
> object to the calling context (which is where the concrete factory is
> know), but the comments seem to make it clear the intention of the
> author.

Ah, it seems I misunderstood something. I think the name
"create_something" fools me , it sounds like a factory method. Sorry.
I suggest the author changes the name .
This topic is locked and can not be replied to.