The Difference between an Anti-Pattern and a Code Smell
I think the term "Anti-Pattern" is being over used. There's various definitions for Anti-Pattern like "obvious but wrong, solutions to recurring problems" and "common approaches to solving recurring problems that prove to be ineffective". All definitions have a common thread: they're recognizable solutions (pattern) that don't work in at least one way and should never be used.
This means that anything that does work, when used correctly, isn't an Anti-Pattern. Transitively, that doesn't make incorrectly used Patterns Anti-Patterns.
Code Smells, on the other hand, are defined as "…a hint that something might be wrong, not a certainty.".
I've seen the term Anti-Pattern used in a couple of places lately that describe scenarios where patterns are used incorrectly. Each and every pattern has a time and a place (a context). Outside of that context, it is not an anti-pattern.
The term Code Smell is much better to describe inappropriate uses of patterns.
For example, Mark Seemann recently blogged that Service Locator is an Anti-Pattern. I disagree. I argue that there is a time and a place for Service Locator. Incorrect use of Service Locator is definitely a code smell—it's an indication (a hint, not a certainty) that there's something wrong with the design. The fact that you're using Service Locator instead of Dependency Injection is, indeed, a design issue. But, dependency injection may not be possible. WebForms, for example. I can't inject dependencies into a web form because I have no control over it's construction. I'm forced to either use a Service Locator or a Factory to aid in my decoupling efforts.
