

Patterns: A Second-Order Tool at Best - silentbicycle
http://parand.com/say/index.php/2005/07/18/i-hate-patterns/

======
russell
Yes. Yes. Patterns are an educational tool. Read the book(s) then put them
away. Adhering to patterns because they are SUPERIOR leads to code bloat and
unwieldy design. The article has a case where EJBs were used when a simple
servlet would have sufficed. My rant-topic-of-the-day is using beans where a
hash would do.

From a comment by Russ Olsen, "People who write this stuff just seem to miss
that the size of the infrastructure needs to be in proportion to the size of
the actual work being done. If the infrastructure is four times the size of
the code that actually does something, then you can rewrite the real code 4
times for the price of the infrastructure."

~~~
triplefox
Indeed. Patterns are what you use when there is no cleaner option for the
situation.

Recently I've been writing some code which is surprisingly amenable to a
cut+paste approach: A tool which automatically generates level layouts for a
game. At first I endeavored towards a data-driven approach to customizing each
type of level I wanted to make, but soon I decided, "There are only six types
of levels. Each one has different requirements and they get maintained in
isolation. There is no point in trying to reconcile all of them at once."

And so I went ahead with a strategy of reuse for the most common elements -
low-level generation strategies - and made big switch statements for the
remainder. It works, I get the job done, and there's almost never anything
surprising. The only time something did surprise me was when I accidentally
pasted the same code twice in different places and threw the results askew in
a non-obvious way. That flags some need to slim down bloated methods, but even
as-is, it still feels pretty slim at ~2500 lines.

