
Design Patterns: Decorator Pattern - henriguy
https://henricodesjava.blog/2017/10/06/design-patterns-decorator-pattern/
======
lowbloodsugar
So many pages on the internet attempt to explain a concept and then do so with
an example that demonstrates a totally inappropriate use of the concept. I'd
go so far as to say that the example is so bad that it no longer demonstrates
the concept at all.

The taco example is an example of an OOP antipattern. Its classic "naive OOP",
i.e. "I can do this, so I should". If the taco where in an order taking
system, a "menu item" object might have an associated list of "condiment"
objects, and these would probably be associations to shared objects. If this
were a video game, there might be separate behavioral and rendering objects,
and the "rendering object" would simply be a number of generic models etc etc.
I understand its hard to provide good examples when writing a blog, but this
is precisely the situation when one should do so. To describe the decorator
pattern and then provide examples that are bad to the point of misinformation
is just lazy.

The decorator pattern is already on sketchy ground IMHO. The wikipedia
entry[1] says its to avoid separation of concerns issue, but it seems to do so
by ignoring the IsA constraint. A WindowDecorator IsNotA Window. A
DecoratedWindow might be a Window, and it might have a list of Decorators, but
I can see all sorts of ways that a specific implementation will have a
radically different class hierarchy.

[1]
[https://en.wikipedia.org/wiki/Decorator_pattern](https://en.wikipedia.org/wiki/Decorator_pattern)

------
winstonewert
Clearly I've drunk too much functional cool aid, all these patterns that I
used to like look like terrible terrible ideas now.

~~~
krat0sprakhar
Serious question: do you consider _all_ the patterns in the gang of four to be
terrible or are there a few you'd recommend to be more useful? As a relatively
young Java developer I'd love to know what patterns have stood the test of
time.

~~~
fragsworth
I can't speak for the original commenter, but I think that book has
(unintentionally) done a lot of damage to software by getting people excited
about things they have no business getting excited about. It's impossible to
read that book as a junior developer and get any use out of it. What
inevitably happens is the junior developer reads it, gets excited about the
patterns, and injects as many patterns as they can into all of the source code
they write. I've done it myself, and I've seen this happen to others time and
time again.

You can accomplish writing perfectly clean, readable, and maintainable
projects that multiple people work on without learning _any_ of the design
patterns in that book. You will probably discover later that you were using
certain patterns without knowing what they were called. The earlier you learn
this, the better off you will be.

~~~
geezerjay
> You can accomplish writing perfectly clean, readable, and maintainable
> projects that multiple people work on without learning any of the design
> patterns in that book. You will probably discover later that you were using
> certain patterns without knowing what they were called. The earlier you
> learn this, the better off you will be.

The main value of learning design patterns is not how or when you use them,
but in the way they establish a common language that people can use to
describe somewhat complex designs and/or the intent behing a design in rather
simple terms. Design patterns facilitate creating conceptual models of
software constructs, thus they help explore ideas and communicate them with
others while focusing on essential aspects and ignoring implementation
details.

For instance, at first glance the strategy pattern may be seen as a fancy word
to describe inheritance, but mentioning inheritance says nothing about the
intent of implementing algorithms as strategies. If, on the other hand,
someone says that a component will be implemented based on a strategy pattern
then it's already implicit that the designer expects that an algorithm should
be exchangeable with ease and also that more versions could be added later
without any trouble.

