Asp Forum - Is this a kind of design patterns?

Sam Kong

3/22/2006 7:17:00 AM

Hi!

Sometimes a class provides object instantiation methods other than new.
See an example.

class Color
def initialize r, g, b
@r = r
@g = g
@b = b
end

def to_s
"R: #{@r}, G: #{@g}, B: #{@b}"
end

class << self
def red
new 255, 0, 0
end

def blue
new 0, 0, 255
end

def green
new 0, 255, 0
end
end
end

puts Color.new(100, 120, 140)
puts Color.red
puts Color.blue

Is this one of design patterns, or just a simple idiom?
It's similar to a factory method pattern but it's not according to the
definition.
Is there any name for it?

TIA.

Sam

22 Answers

killy-kun

3/22/2006 8:45:00 AM

Daniel Baird

3/22/2006 9:35:00 AM

The truth is, as a ganeral rule the original G4 design patterns were kinda
statically-typed-language-centric, so it wouldn't surprise me if there was
some small details in Ruby versions of the patterns that didn't quite fit
the "classic" description.

In this case though, it does look a lot like the Factory pattern, apart from
new still being available. I think if Color.new was re-declared as private,
that would make it a textbook case of the Factory pattern.

IANA(language)L though..

;Daniel

On 22/03/06, killy-kun <killy-kun@wanadoo.fr> wrote:
>
> Sam Kong wrote:
> > Hi!
> >
> > Sometimes a class provides object instantiation methods other than new.
> > See an example.
> >
> > class Color
> > def initialize r, g, b
> > @r = r
> > @g = g
> > @b = b
> > end
> >
> > def to_s
> > "R: #{@r}, G: #{@g}, B: #{@b}"
> > end
> >
> > class << self
> > def red
> > new 255, 0, 0
> > end
> >
> > def blue
> > new 0, 0, 255
> > end
> >
> > def green
> > new 0, 255, 0
> > end
> > end
> > end
> >
> > puts Color.new(100, 120, 140)
> > puts Color.red
> > puts Color.blue
> >
> >
> > Is this one of design patterns, or just a simple idiom?
> > It's similar to a factory method pattern but it's not according to the
> > definition.
> > Is there any name for it?
> >
> > TIA.
> >
> > Sam
> >
>
> isn't that the facory design pattern ?
>
>

--
Daniel Baird
http://danie... (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things
That Suck)
[[My webhost uptime is ~ 92%.. if no answer pls call again later!]]

Robert Klemme

3/22/2006 1:21:00 PM

Sam Kong wrote:
> Hi!
>
> Sometimes a class provides object instantiation methods other than new.
> See an example.
>
> class Color
> def initialize r, g, b
> @r = r
> @g = g
> @b = b
> end
>
> def to_s
> "R: #{@r}, G: #{@g}, B: #{@b}"
> end
>
> class << self
> def red
> new 255, 0, 0
> end
>
> def blue
> new 0, 0, 255
> end
>
> def green
> new 0, 255, 0
> end
> end
> end
>
> puts Color.new(100, 120, 140)
> puts Color.red
> puts Color.blue
>
>
> Is this one of design patterns, or just a simple idiom?
> It's similar to a factory method pattern but it's not according to the
> definition.
> Is there any name for it?

Since you invoke a class's method "new" like any other method of any
other object (no special syntax) you can say with some justification
that all classes are basically factories.

IMHO your example is not optimal because it wastes resources. Since
Color is immutable anyway constants seem a better choice:

Color = Struct.new :r, :g, :b
class Color
def to_s
sprintf "R: 0x%02x, G: 0x%02x, B: 0x%02x", self.r, self.g, self.b
end

RED = new 0xFF, 0x00, 0x00
BLUE = new 0x00, 0x00, 0xFF
GREEN = new 0x00, 0xFF, 0x00
end

Kind regards

robert

Wilson Bilkovich

3/22/2006 2:14:00 PM

On 3/22/06, Sam Kong <sam.s.kong@gmail.com> wrote:
> Hi!
>
> Sometimes a class provides object instantiation methods other than new.
> See an example.
>
> class Color
> def initialize r, g, b
> @r = r
> @g = g
> @b = b
> end
>
> def to_s
> "R: #{@r}, G: #{@g}, B: #{@b}"
> end
>
> class << self
> def red
> new 255, 0, 0
> end
>
> def blue
> new 0, 0, 255
> end
>
> def green
> new 0, 255, 0
> end
> end
> end
>
> puts Color.new(100, 120, 140)
> puts Color.red
> puts Color.blue
>
>
> Is this one of design patterns, or just a simple idiom?
> It's similar to a factory method pattern but it's not according to the
> definition.
> Is there any name for it?
>

That's the "Factory Method" pattern. It's handy when you want
SomeClass.new to return an instance of SomeOtherClass, or just when
you want things to be easier to read.

One of my favorite examples (I think this is a Martin Fowler trick) is:
some_date = december(10,2006)

Sam Kong

3/22/2006 4:53:00 PM

Wilson Bilkovich wrote:
> That's the "Factory Method" pattern. It's handy when you want
> SomeClass.new to return an instance of SomeOtherClass, or just when
> you want things to be easier to read.
>
> One of my favorite examples (I think this is a Martin Fowler trick) is:
> some_date = december(10,2006)

At first I thought so.
But the definition of "Factory Method Pattern" bothered me.
The definition of "Factory Method Pattern" is:

"Define an interface for creating an object, but let subclasses decide
which class to instantiate. Factory Method lets a class defer
instantiation to subclasses. "

However, in my Color example, there's no subclassing involved.
So the class itself is a factory as well as the product that the
factory makes.
Do you think that we can still call it "Factory Method Pattern"?

Sam

Sam Kong

3/22/2006 4:59:00 PM

Robert Klemme wrote:
> Sam Kong wrote:
> > Hi!
> >
> > Sometimes a class provides object instantiation methods other than new.
> > See an example.
> >
> > class Color
> > def initialize r, g, b
> > @r = r
> > @g = g
> > @b = b
> > end
> >
> > def to_s
> > "R: #{@r}, G: #{@g}, B: #{@b}"
> > end
> >
> > class << self
> > def red
> > new 255, 0, 0
> > end
> >
> > def blue
> > new 0, 0, 255
> > end
> >
> > def green
> > new 0, 255, 0
> > end
> > end
> > end
> >
> > puts Color.new(100, 120, 140)
> > puts Color.red
> > puts Color.blue
> >
> >
> > Is this one of design patterns, or just a simple idiom?
> > It's similar to a factory method pattern but it's not according to the
> > definition.
> > Is there any name for it?
>
> Since you invoke a class's method "new" like any other method of any
> other object (no special syntax) you can say with some justification
> that all classes are basically factories.
>
> IMHO your example is not optimal because it wastes resources. Since
> Color is immutable anyway constants seem a better choice:
>
> Color = Struct.new :r, :g, :b
> class Color
> def to_s
> sprintf "R: 0x%02x, G: 0x%02x, B: 0x%02x", self.r, self.g, self.b
> end
>
> RED = new 0xFF, 0x00, 0x00
> BLUE = new 0x00, 0x00, 0xFF
> GREEN = new 0x00, 0xFF, 0x00
> end

This looks tricky and wonderful.
I just tried to make a simple example which was not intended to be
ooptimal.
I will apply your way when I need to make a real code.:-)
Thank you.

Sam

Pete

3/22/2006 5:14:00 PM

my personal definition:

factory method:
method, that creates a object,
because new(...) is not sufficient
in that case

imho there's too much babbling about design patterns und too
little pragmatism. who cares if it's pattern #1 or pattern #2.

it's more a matter of good taste as a matter of applying rules.

especially in java I have seen ridiculous numbers of classes doing
trivial stuff using factories, abstract classes, interfaces, proxies,
adapters, delegates and the like. it's often considered by so called
architects to be good software if it uses several design pattern
no matter what for...

> --- Ursprüngliche Nachricht ---
> Von: "Sam Kong" <sam.s.kong@gmail.com>
> An: ruby-talk@ruby-lang.org (ruby-talk ML)
> Betreff: Re: Is this a kind of design patterns?
> Datum: Thu, 23 Mar 2006 01:53:51 +0900
>
>
> Wilson Bilkovich wrote:
> > That's the "Factory Method" pattern. It's handy when you want
> > SomeClass.new to return an instance of SomeOtherClass, or just when
> > you want things to be easier to read.
> >
> > One of my favorite examples (I think this is a Martin Fowler trick) is:
> > some_date = december(10,2006)
>
> At first I thought so.
> But the definition of "Factory Method Pattern" bothered me.
> The definition of "Factory Method Pattern" is:
>
> "Define an interface for creating an object, but let subclasses decide
> which class to instantiate. Factory Method lets a class defer
> instantiation to subclasses. "
>
> However, in my Color example, there's no subclassing involved.
> So the class itself is a factory as well as the product that the
> factory makes.
> Do you think that we can still call it "Factory Method Pattern"?
>
> Sam
>
>

Jim Weirich

3/22/2006 6:32:00 PM

Robert Klemme wrote:
> Sam Kong wrote:
>> end
>> def blue
>> puts Color.red
>> puts Color.blue
>>
>>
>> Is this one of design patterns, or just a simple idiom?
>> It's similar to a factory method pattern but it's not according to the
>> definition.
>> Is there any name for it?
>
> Since you invoke a class's method "new" like any other method of any
> other object (no special syntax) you can say with some justification
> that all classes are basically factories.
>
> IMHO your example is not optimal because it wastes resources. Since
> Color is immutable anyway constants seem a better choice:
>
> Color = Struct.new :r, :g, :b
> class Color
> def to_s
> sprintf "R: 0x%02x, G: 0x%02x, B: 0x%02x", self.r, self.g, self.b
> end
>
> RED = new 0xFF, 0x00, 0x00
> BLUE = new 0x00, 0x00, 0xFF
> GREEN = new 0x00, 0xFF, 0x00
> end

I was thinking along the same lines, but I do like the method interface
(e.g. Color.red over Color::RED). My suggestion would have been
something like:

class Color
...
class << self
def red
@red ||= new 255, 0, 0
end
...
end
end

--
-- Jim Weirich

--
Posted via http://www.ruby-....

Sam Kong

3/22/2006 6:36:00 PM

Peter Ertl wrote:
> my personal definition:
>
> factory method:
> method, that creates a object,
> because new(...) is not sufficient
> in that case
>
> imho there's too much babbling about design patterns und too
> little pragmatism. who cares if it's pattern #1 or pattern #2.
>
> it's more a matter of good taste as a matter of applying rules.
>
> especially in java I have seen ridiculous numbers of classes doing
> trivial stuff using factories, abstract classes, interfaces, proxies,
> adapters, delegates and the like. it's often considered by so called
> architects to be good software if it uses several design pattern
> no matter what for...

You may be right.
However, knowing the right definition is important for communcation.
If somebody tells you to make a class using "X" pattern, you need to
understand what "X" pattern means.
The pattern names might have been arbitrarily made but now it's very
common almost like a standard.

Sam

Jim Weirich

3/22/2006 6:37:00 PM

Peter Ertl wrote:
> imho there's too much babbling about design patterns und too
> little pragmatism. who cares if it's pattern #1 or pattern #2.

The value of patterns is the vocabulary it gives to developers.

> it's more a matter of good taste as a matter of applying rules.
>
> especially in java I have seen ridiculous numbers of classes doing
> trivial stuff using factories, abstract classes, interfaces, proxies,
> adapters, delegates and the like. it's often considered by so called
> architects to be good software if it uses several design pattern
> no matter what for...

Ahh, now this I agree with. People get it in their heads that patterns
are good, what they forget is that every pattern solves a given problem
with a set of tradeoffs. Understanding the tradeoffs is crucial to
fully understanding the pattern. Too many people blindly apply the full
blown pattern right out of the GOF book without considering the costs.

Beware of programmers who have just learned a new pattern and are
looking for a place to apply it.

--
-- Jim Weirich

--
Posted via http://www.ruby-....

comp.lang.ruby

Is this a kind of design patterns?

Sam Kong

killy-kun

Daniel Baird

Robert Klemme

Wilson Bilkovich

Sam Kong

Sam Kong

Pete

Jim Weirich

Sam Kong

Jim Weirich

x Login to ForumsZone