"Darren New" <dne### [at] sanrrcom> wrote in message
news:486eda2e$1@news.povray.org...
> Is it me, or is the GoF book "Design Patterns" really over-hyped? Every
> time I hear it mentioned, it's along the lines of "wow, isn't it great
> they teach you all these tricks?"  When really, all they're doing is
> naming stuff that everyone does, most of which predates OO programming
> to start with.

I haven't read it, though I have read some other books on patterns, so this
is just my take.

Firstly, having standard names for things makes communication easier. System
designer can just say "I want you to use a Abstract Factory" and in theory
the developer nows exactly what to do.
I've seen patterns described as 'documented good practices'. They're
probably more useful for the average developer than for the gurus because
they show something that does work (if used in the right circumstances)

Post a reply to this message

There really *are* design patterns which might sound obvious to you
and me, but are not all that obvious to many programmers who are starting
to dig into OOP.

  One example I like (and which name I rather ironically cannot remember
now) is the design pattern which you can use to create primitives and
unions of primitives, so that the union itself is a primitive (thus
allowing a union to contain other unions, containing other unions,
thus forming a whole hierarchy of primitives).

  For example, let's assume that you have three primitives: Line, rectangle
and circle, and you also want to be able to make compound objects containing
any amount of those (so that you can, for example, transform all of them
as if they were one single primitive). Of course it would be nice if such
a compound object could contain other compound objects as well. Thus this
compound object should be a primitive itself.

  Hence the inheritance hierarchy would be something like this:

Primitive
  '--> Line
  '--> Rectangle
  '--> Circle
  '--> Union
         '--Contains: List of <Primitive>

  In other words, if that was drawn as an UML diagram, there would be
a "contains" arrow from 'Union' back to 'Primitive', making the hierarchy
recursive.

  This is a simple idea and might be obvious to some, but it certainly
might not obvious to the new OO programmer.

  The book Design Patterns is full of tidbits like this, making it
potentially quite useful to someone.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   There really *are* design patterns which might sound obvious to you
> and me, but are not all that obvious to many programmers who are starting
> to dig into OOP.
> 
>   One example I like (and which name I rather ironically cannot remember
> now) is the design pattern which you can use to create primitives and
> unions of primitives, so that the union itself is a primitive (thus
> allowing a union to contain other unions, containing other unions,
> thus forming a whole hierarchy of primitives).

It's called Container or Composite or something like that. (Also related 
to the Decorator pattern - although that does the same thing for a 
different reason.)

>   This is a simple idea and might be obvious to some, but it certainly
> might not obvious to the new OO programmer.

Many good ideas seem obvious *after* somebody told you. ;-)

For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but 
DAMN... I've have never thought of it!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote in message
news:486f38f7$1@news.povray.org...
>
> Many good ideas seem obvious *after* somebody told you. ;-)

Which is as good a reason as any to make the patterns known. So we don't get
novice programmers who just don't know the tried and trusted ways
reinventing the wheel, usually badly.

Post a reply to this message

Orchid XP v8 wrote:
> For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but 
> DAMN... I've have never thought of it!
> 
Well that is true for some values of A an B - But probably not as many 
as you think.

Whereas (A+B)^2 - 4*(A+B) = (A-B)^2 is true a few more cases.

Unless you have redefined the * and + operators :)

Post a reply to this message

>> For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but 
>> DAMN... I've have never thought of it!
>>
> Well that is true for some values of A an B - But probably not as many 
> as you think.
> 
> Whereas (A+B)^2 - 4*(A+B) = (A-B)^2 is true a few more cases.
> 
> Unless you have redefined the * and + operators :)

NAAAAARGH!!! >_<

Why must every point I make be compromised by flawed typing?!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Paul Fuller" <pgf### [at] optusnetcomau> wrote in message
news:486f6167$1@news.povray.org...
> Orchid XP v8 wrote:

> > For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but
> > DAMN... I've have never thought of it!

> Well that is true for some values of A an B - But probably not as many
> as you think.
>
> Whereas (A+B)^2 - 4*(A+B) = (A-B)^2 is true a few more cases.

Still, not true for as many cases as

(A+B)^2 - 4*A*B = (A-B)^2

Post a reply to this message

Warp wrote:
> Primitive
>   '--> Line
>   '--> Rectangle
>   '--> Circle
>   '--> Union
>          '--Contains: List of <Primitive>

I was doing that before I knew what "Design Patterns" were.

>   The book Design Patterns is full of tidbits like this, making it
> potentially quite useful to someone.

Actually, I think it would be extremely beneficial to me, just for the 
standard terminology.  While there are patterns I don't know, more 
important to me is being able to communicate with other people the ideas 
in my head.

...Chambers

Post a reply to this message

Orchid XP v8 wrote:
>>> For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but 
>>> DAMN... I've have never thought of it!
>>>
>> Well that is true for some values of A an B - But probably not as many 
>> as you think.
>>
>> Whereas (A+B)^2 - 4*(A+B) = (A-B)^2 is true a few more cases.
>>
>> Unless you have redefined the * and + operators :)
> 
> NAAAAARGH!!! >_<
> 
> Why must every point I make be compromised by flawed typing?!
> 

Because you don't type enough?

I recommend you spend *more* time on these forums, and tell your boss 
you're improving your work skills :)

...Chambers

Post a reply to this message

somebody wrote:
> "Paul Fuller" <pgf### [at] optusnetcomau> wrote in message
> news:486f6167$1@news.povray.org...
>> Orchid XP v8 wrote:
> 
>>> For example, (A*B)^2 - 4*(A+B) = (A-B)^2. Obvious once you know, but
>>> DAMN... I've have never thought of it!
> 
>> Well that is true for some values of A an B - But probably not as many
>> as you think.
>>
>> Whereas (A+B)^2 - 4*(A+B) = (A-B)^2 is true a few more cases.
> 
> Still, not true for as many cases as
> 
> (A+B)^2 - 4*A*B = (A-B)^2
> 
> 
> 
Now we're on to something.  Give this a few more iterations and we'll be 
proving something worthwhile :)

Post a reply to this message