Pleas do not top post. It is going to make this thread hard to read...

I like the decorator pattern..  In fact the Head First's Design Patterns
book has a nice chapter on it.

Thanks in Advance...
IchBin, Pocono Lake, Pa, USA              http://weconsultants.phpnet.us
__________________________________________________________________________

'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor,  Regular Guy (1952-)

And that is why they are called *design* patterns, not *implementation*
patterns.  It sounds like you get it.  Unfortunately, a lot of programmers
do not, and horribly confuse the design process with the implementation
process.

+1

(Except that I when I notice I'm using a pattern I've seen before, I
sometimes review the GoF book to see whether I'm doing it "right. :)

   Another reason it might be handy to learn about DPs is that it might
show you a new solution you hadn't thought of before. Before seeing MVC in
university, it hadn't occured to me to seperate the model from its
representation, for example.

   To address the OP: As with everything else in programming, DPs are
tools. Use the right tool for the job. Sometimes DPs aren't the right tools.

   - Oliver

Wow, I'm in about 100% disagreement with you over this.  Although
patterns tend to play some role in building vocabulary, this is
secondary to their purpose, which is to get people to recognize and
think about good design practices that have arisen from long experience
in a variety of situations.  I start to get skeptical when I'm talking
to someone who throws around too many design pattern names in
conversation.

I also think that using design pattern names as shorthand for discussing
designs is potentially limiting in terms of design possibilities.  This
is, in a sense, a form of Sapir-Whorf for object oriented design.  I
worry about a book being taken as the specification for "correct" use of
a pattern.  The book is no more knowledgable than the programmer about
the concerns of a specific application.  There are many variations in
design that might make sense, but that may not be considered if there's
too much focus on what pattern is being used.  In particular, there is
considerable danger that when I use a word to describe a general design
idea, someone else may read into that some specific implementation
decisions that I didn't intend to convey.  This possibility becomes
increasingly likely as programmers intensionally try to use design
pattern names to convey more meaning.  For this reason, I tend to avoid
the practice like the plague.

On the other hand, I do think that patterns have an impact on the design
process.  Specifically, they play a role in learning design.  Reading
the GoF book on design patterns is sort of an aha! experience for many
developers I've spoken to who attribute that book with getting them to
start understanding how OO concepts can be used to solve problems.  Even
outside of that task, good patterns encapsulate ideas that really do
come up again and again in software design, so that being aware of them
helps when similar situations arise.  The problem, of course, is that
this only works when you trust your sources of patterns.  I tend to
think that the GoF book has a pretty high rate of patterns really being
"tried and tested" techniques.  Other sources are not so good.  Patterns
that originated in blogs ought be view with extreme suspicion.

I would, again, think the opposite.  If someone had never heard of a
factory, then I might view this with extreme suspicion... but factories
have been around much longer than patterns.  If someone implemented a
factory differently than my favorite patterns book, this would be no
problem.  Additionally, I'd view never having heard of a "singleton" by
an experienced programmer as surprising, but not necessarily a
disqualification unless it indicates that the programmer is actually not
so experienced.

I find that people portray arrogance by deferring too much real
conversation when the design phase is occuring.  It makes them look
managerial and "big picture" and "open". (brains pouring out open).

It is fine to defer solutions of course when talking requirements or a
certain level of specifications but often, as you mention, talking
about the design, often the design that already exists seems
appropriate. When talking about a new design, it is good to make
decisions quickly...however, it seems equally important to remember
that no single design should be instant solution and that it is good to
get two or more on the table sometimes and pick the best one. That is
sometimes why people seem to not want to talk about a particular
pattern is so that they can keep the implementation idea open. However,
too often, it is because they have already decided against it.
Constantly keeping options open is not "pragmatic" and is part of the
"paralysis". Sometimes, a senior developer is good about making a
careful decision but over time, they can get paranoid about this and
they more than anyone tend to be like this anecdotally from my own
experience.

What is very annoying is to try to limit someone's conversation from
talking about anything because more often, people bring difference
experiences and it is extremely arrogant and narrow minded (ironically)
to not listen or to be judgemental about someone's ideas because of
particular personality clashes/biases, etc. It is more productive to at
least consider options and ideas but also to give everyone some equal
amount of time. Otherwise, some people spiral down out of politics when
they often have been the type to do tremendously well in other
situations where personality was not an issue.

I'd agree there...

I've tended to pick up patterns by doing them and later recognizing
them or sometimes playing with one that sounds good and then doing some
proof and discovering how well it works. In order, I learned:

Singleton
Factory (and how they can help keep a more pure interface like design.)
Facade
Composite
Adapter
Observer
Decorator
Strategy
Visitor
Memento
Little Language
(I'm aware of others but haven't had the projects that would make use
of them.)

The observer has so many synonymns in the real world that it is the
simplest and most confusing at the same time. But it is one I've really
started to fall in love with and has almost become a golden hammer of
sorts. It has been most appropriate for my latest project.

Aside note without further addressing the OP here, a few anti-patterns
I find are useful conversationally but I find they may have more to do
with strategy than an implementation tactic other than say "spaghetti".
Does anyone own that book? I had talked about it so much without
actually owning a book that not long ago, I acquired it just for that
reason. It seems again a useful kind of language enhancer. Often,
Refactoring and Pattern go hand in hand and refactoring includes the
reverse pattern depending on situations. Those might be more truly
anti-pattern but strangely, some anti-patterns can be "good patterns"
in some scenarios.

Some design patterns certainly simplify code.  For example, using a
common manager object to coordinate interactions between a large set of
other objects (which GoF calls the Mediator pattern) is a simplifying
tool.  So are plenty of other patterns.

There's something wrong with saying what "design patterns" do or don't
do in terms of specific benefits or goals of design.  Different patterns
do different things, obviously.

A bit of a straw man argument there Ed, unless the code is written a by
Pattern Obsessed Dev.

Otherwise, there the AbstractFactory pattern shown above is there for a
particular purpose.  That purpose being to allow a different form of
Apple to be create at runtime, for some purpose.

The is a great way of injecting runtime dynamic changes into the design.
Its especially useful for :   Frameworks, Unit testing, etc.....

If this dynamic changeability isn't needed, then you wouldn't use the
Abstract Factory, you'd just use the standard instantiation approach
('new Apple()'  )

Ed skrev:

<snipped straw man>

Yeah, forget my last post. I was wrong.

Apologies.

.ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html

Indeed, this is THE problem with design patterns as practiced today,

I haven't seen this.  I'd be concerned by it if I saw it.

YES!  Thanks for saying that.  I'm afraid I've been less eloquent so
far.

They did indeed.  For me the point where the madness becomes unmistakable was
when they started talking about pattern /languages/ instead of
/vocabularies/ -- completely losing any sense of proportion, or of what the
value of patterns really is.

I have ranted on this subject before in this group ;-)

But that doesn't make patterns valueless themselves.

Agreed entirely.  It's a point that seemed to be lost on some of the pattern
wanke^H^H^H^H^H^H enthusiasts.

   -- chris

Three consequences, at least.  What you describe below is another unfortunate
consequence.

...

(c) People start calling everything they do a "design pattern".

To be a design pattern, something has to come up in fairly common practice,
not just one artificial program.  The point is that design patterns are
solutions to problems that are common, so that they will come up again and
again and again, so having a name for them makes for efficient
communication.  For something like what you are describing with "Type
Object", it sounds like no sane person would give a damn about it.

The same misconception that leads to (c) is also responsible for (a).
Design patterns are found or noticed, not invented.