OK, I'm not looking for anti-patterns - I'm looking for things that aren't really patterns, or perhaps patterns that have been abused.
My personal least favourite is the "Helper" pattern.
E.g. I need to create a SQL query, so call SQLQueryHelper. This needs to process some strings, so it in turn calls StringHelper. Etc., etc.
See - this isn't really a design pattern at all...
[edit] Don't you people who vote this down think you should add a constructive remark?
Singleton.
It's a global variable in disguise and difficult to mock/stub for unit testing.
Service Locator better, Dependency injection / Inversion of Control better still.
The majority of references on the wikipedia article are about why it is evil.
'Manager' classes. e.g.
DataManager
BusinessLogicManager
WidgetManager
What the **** does 'Manager' mean? Be more specific! If your WidgetManager has so many Widget responsibilities that there is no more specific name, then break it down.
This is a conversation I have had too many times with myself when looking at old code.
I think that Design Patterns should not be used blindly, implementing them simply because it's cool: they have a well-specified CONTEXT, and using them when appropriate MAY help, but in any other case they're just a waste of time, when not an hindrance to the correct system functioning.
MVP. It's MVC but broken.
Oh no but wait, developing an application IS completely different than following good practise such as "It's just a view".
Update
I reference "It's just a view" which is from the book Pragmatic Programmer. My main issue is that almost every single MVP implementation has the view holding onto the presenter and telling the presenter to do things. This is conceptually backwards. The UI should not have a dependancy on the logic. It is "just a view". The logic is the primary reason for the application, how that logic is displayed is a secondary concern. I could use one winform, or I could use many. Hell, I could pipe the whole thing out into ASCII text, or create the "view" by sending charges down a wire attached to an artist who renders the view via the medium of interperative dance.
Practically speaking this premise does have some viable uses. Some of the controllers I've written in the past have MANY views that are exernally exposed and can be pushed into the UI as the application sees fit. Consider a live feed of data. I could present this as stats, as lines graphs, as pie charts. Perhaps all at the same time! Then the view holding onto the controller looks kinda silly, the parent is the controller and the children are the views.
A traditional (Form holds presenter) MVP implementation has other consequences. One being that your UI now has a dependancy on code that performs the logic, this means it will also require references to everything that logic needs (services etc).
The way to fix this is to pass in an interface (again, most MVP implementation I see have the form creating the presenter, but hey). Then it becomes a workable model, although i've never been a fan of passing in args to a form constructor.
At the end of day it feels like people are twisting things around attempting to justify a model that is broken. I am of the personal belief that the MVP pattern purely exists as an attempt to rationalise how Visual Studio Windows Forms Applications work. They start with a "Form First" mentality.
"Oh hai, here is your form, now go and draggy drop your controls and stuff logic into the UI"
Anyone with experience with any apps that are beyond a util appreciate that this way of working does not scale. I see MVP as a way of making this scale but this just feels like an architectural band aid around the broken "form first" development model the IDE promotes.
I argue that MVC is just MVC, MVP is a bastardisation of the pattern. Infact the whole definition of MVC is kinda backwards. The important part of it is separation of concerns. The UI, the logic, the data and/or services you're consuming. Keep these seperate. You don't implement MVC to do this, you do this and by doing so you end up with a form of MVC. MVP doesn't fit into this because you don't end up with MVP if you start by thinking of Separation of Concerns you end up with MVP if you're stuck in "Form First" land and you feel you should be doing things a bit more MVCish.
That's my take on it anyway....
Strategy
The reason being that I suspect most people are taught to implement it using a class and a method.
Consider the following Haskell code:
ascending = sortBy compare somelist
descending = sortBy (flip compare) somelist
pairsBySecondComponent = sortBy (comparing snd) somelist
That's the strategy pattern in action: compare, (flip compare) and (comparing snd) are the concrete strategies in this case (they're plain old functions), and the function signature a -> a -> Ordering is the strategy "interface".
The brevity of this illustrates that design patterns don't have to be so heavyweight or bulky. The way you want to implement Strategy in Java (interface, classes) is not a good way. It's a way that works around Java giving you the wrong abstractions for the job you need to do. This should not be considered normal or acceptable.
For that reason, assuming my assumption about the way it's taught is correct, I don't like the Strategy pattern very much.
There are some of other patterns which are also specific instances of the general "Function Pointer" pattern. I don't like them very much either, for very much the same reasons.
My least favourite is the "put 'Helper' or 'Manager' on to the end of the class name" pattern.
EDIT: And I've proved that I'm a lame programmer by, as Chris pointed out, forgetting "Util".