Anti Patterns Catalog
c2.com
Anti Patterns Catalog
1–10 of 10 posts
Re: Anti Patterns Catalog
#2I've suspected for a long time that a knowledge of anti-patterns is of more practical benefit that a knowledge of GoF design-patterns.
Re: Anti Patterns Catalog
#3I've suspected for a long time that a knowledge of anti-patterns is of more practical benefit that a knowledge of GoF design-patterns.
Most people know GoF DP _and_ practice more AntiPatterns so I have to agree with you here... the net result is a big negative.
Re: Anti Patterns Catalog
#4I've suspected for a long time that a knowledge of anti-patterns is of more practical benefit that a knowledge of GoF design-patterns.
Especially since, in my experience, you're more likely to come across anti-patterns than proper design-patterns. It is nice, though, to quantify the idiocy with succinct names.
Re: Anti Patterns Catalog
#5I'd like to add http://sourcemaking.com/antipatterns as another place to learn about anti-patterns. Recommended read.
Re: Anti Patterns Catalog
#6This 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.
Re: Anti Patterns Catalog
#7I've suspected for a long time that a knowledge of anti-patterns is of more practical benefit that a knowledge of GoF design-patterns.
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.
Re: Anti Patterns Catalog
#8This 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…
See my other comment on how anti-patterns are supremely useful when you're working in a brownfield (existing subpar codebase, project, etc.) and you need to recognize the problems and having suggestions about how to fix them is very helpful.
You can also try reading the anti-patterns book for an introduction to many of the most important ones, or rather books: http://www.amazon.com/s?index=blended&link_code=qs&f...
Although I can only vouch for the tremendous usefullness of the first: http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...
Hmmm, I think it went out of print but it's back.
Re: Anti Patterns Catalog
#9This 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…
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.
Re: Anti Patterns Catalog
#10This 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…
I think this could be condensed somewhat. For example, the Jumble seems similar to Big Ball o' Mud, while Junkyard Coding, Stovepipe, and Rube Goldberg Machines all share characteristics.
I'd also like to see design/programming patterns distinguished from organizational patterns like Empire Building or Hero Culture (though not surprisingly, they tend to be correlated with each other.)
Regarding the commonality of these patterns, having worked in an Oracle environment for a while, the ones I see most often seem to be Stovepipe systems and Big Ball of Mud. SQL in particular tends to force a stovepipe approach, because if you try to hide too much complexity behind nice PL/SQL interfaces, you tend to get highly suboptimal explain plans, and/or, you end up losing advantages of multi-block I/O and batch processing. So, instead, you have huge multi-table joins that are inherently brittle and difficult to maintain but which perform adequately. (Yes, views can help here to some degree.)
Because you don't have many clean interfaces, refactoring becomes more difficult and you also get tons of copy/paste code, resulting in an eventual Big Ball of Mud.