
Anti Patterns Catalog - fogus
http://c2.com/cgi/wiki?AntiPatternsCatalog
======
rauljara
This is a great resource, but I suspect it will soon become overwhelming.
There are an infinite number of anti-patterns. There may also be an infinite
number of good design patterns as well. But just as y = x, and y = x^2 both
approach infinity, one of those formulas approaches a lot faster. The number
of bad design patterns out there to look at is just staggering. For anti-
patterns to be useful to study, there would have to be some ranking based on
how common they are. Otherwise, studying the one or two "right" ways to solve
your problem seems like the only practical way to go.

~~~
derefr
Regular patterns are usually matters of intent—being able to say "this code
should have patterns X, Y, and Z" doesn't help you at all if those patterns
aren't coherent to the goals of the code. However, "this code _shouldn't_ have
patterns X, Y, or Z" _is_ useful, and therefore could be made to be checked
automatically. Anti-patterns would then become like virus signatures in a
codebase, found during compilation.

------
arethuza
I've suspected for a long time that a knowledge of anti-patterns is of more
practical benefit that a knowledge of GoF design-patterns.

~~~
hga
The key here is to take the approach of the invaluable anti-patterns book and
apply your recognition of an anti-pattern into how to refactor it into
something better (or get the hell out if you can't).

It's also worth noting that greenfields projects tend to be rare in our field,
more often you're starting with an existing brownfield code base. GoF
addresses the former, anti-patterns directly address the latter, although it's
of course useful to know about anti-patterns so that you can avoid falling
into them when you've got a greenfield to start with.

