Am I the only one that sometimes take the seemingly easy, but wrong, way out of certain design situations? I'll admit I've made my share of questionable Singleton objects. Besides that, I've been known to make a God object or two to make things seem easier.
Do you ever use an anti-pattern even though you know you shouldn't?
It is very easy trying to make something flexible, and ending up with the Inner Platform Effect. I'm guilty of inner-databases, for example.
And sometimes it is too tempting to code things yourself rather than use that pre-canned similar version - Not Invented Here. I try to avoid it, but...
The God Object anti-pattern is an easy mistake to make. Sometimes it can seem like too much work to break classes up. Then at some point later you pay for it. I have found this anti-pattern goes hand in hand with tight coupling.
The vendor lock-in anti-pattern can also be a hard one to avoid when you're using vendor specific languages.
you can find more info in SO itself:
In the comments and I think It's warrants being an answer - the Singleton pattern.
It is a way of achieving global variables when a language (such as Java) doesn't support it. This is one of those patterns where you should never use - except when you need it. The important bit is being able to differentiate between when you need to have a global variable (there are instances) and when you just want one.
There are problems with singletons beyond the serious problems of introducing global state, in Java for instance they are only single within the class loader with multiple class loaders you can end up multiple copies.
There is always that one vendor specific thing that gets added for a specific piece of functionality since it makes more sense than writing it yourself. I've spent much time kicking myself for this decision later on.
