To be clear, I think Design Patterns have their place. When used properly, they can make our lives easier and our code better. When they're misused – "If the only tool you have is a hammer.." – then they can become the bane of our existence. Unfortunately, some Design Patterns seem more susceptible to this than others.
So maybe this is less "design patterns I hate" and more of "design patterns that have been abused beyond all sense of reason"… I'll let you decide.
First, we have Active Record. As the foundation of many of the MVC frameworks out there, this seems like an odd choice, but the explanation is simple. Somewhere along the way, people started pushing the idea of a row of the database as the Model. We mapped columns into properties, added some methods, and considered it complete. While that follows the OO principle of data encapsulation, it misses a key point in the definition of a Model:
The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
The key point is simple. The Model describes the data based on the application domain, not based on the database structure. In fact, it says nothing about storage or persistence of any kind. The Model is an object that fully encapsulates one particular piece object and all of the business logic that goes with it. If it happens to map one-to-one with a database object, it's a useful coincidence, not a sign to combine the two.
Next, we have the Factory Pattern. A Factory Pattern is used when your code needs to figure out which type of class to instantiate at runtime. In concept, that's very powerful and when combined with other Object Oriented aspects – like uniform interfaces – you can build powerful structures that can be flexible and easily extensible. But – as we know – with great power comes responsibility.
A Factory has to make the decision on which class to instantiate. This decision can be as simple as an if/else but normally doesn't end there and becomes a switch/case statement. This in itself isn't bad, it's just more complex. Eventually, someone realizes that they have to load numerous common parameter, so they feed these parameters into the constructor. Since it's so easy to add parameters to a function, they add a few more. Somewhere along the line, some of the parameters conflict with one another and need additional validation and decision logic. At some point, someone realizes that passing in a configuration object would be easier, but often there are different types of configuration objects, so someone decides to build a Factory for that.
Lather, rinse, repeat.
With inappropriate use, we end up with a set of Factory Factories and layer upon layer of logic just to instantiate our classes. BenjiSmith explains it in more painful detail here. It's somewhere between difficult and impossible to test every possible path.
And of course, the ever-hated Singleton. Somewhere along the line, we realized that global variables are bad. Of course, there are still some limited scenarios where they make sense, so we were faced with a problem. We needed something that looked like a global and acted like a global but wasn't really a global.
Enter the Singleton Pattern..
It is a simple pattern that makes sure there is only ever one and only one instance of itself. If you modify that instance, you're modifying it for anything and everything that might use it. This makes sense for resource-heavy objects like database connections but in practice, it's often just a global hiding out as OOP.
All of that said, I don't actually hate these Design Patterns. This particular patterns – and probably many others – have been misused and abused to the point of mangling what would otherwise be useful code. There are correct ways of applying these patterns and times to make use of them..
And no, not everything is a nail.