Design Patterns are … Come on, you know what they are. They are something we love and hate. We love them because they let us write code without thinking. We hate them when we see the code of someone who is used to writing code without thinking. Am I wrong? Now, let me try to go through all of them and show you how much I love or hate each one. Follow me, in alphabetic order.
Abstract Factory. It’s OK.
Adapter. Good one!
Bridge. Good one!
Builder. Terrible concept, since it encourages us to create and use big, complex objects. If you need a builder, there is already something wrong in your code. Refactor it so any object is easy to create through its constructors.
Chain of Responsibility. Seems fine.
Command. It’s OK.
Flyweight. It’s a workaround, as I see it, so it’s not a good design pattern. I would recommend you not use it unless there is a really critical performance issue. But calling it a design pattern … no way. A fix for a performance problem in Java? Yes.
Lazy Initialization. It’s OK.
Mediator. I don’t like it. Even though it sounds like a technique for decreasing complexity and coupling, it is not really object-oriented. Who is this mediator? Just a “channel” between objects? Why shouldn’t objects communicate directly? Because they are too complex? Make them smaller and simpler, rather than inventing these mediators.
Module. If Wikipedia is right about this pattern, it’s something even more terrible than the Singleton.
Multiton. Really bad idea. Same as Singleton.
Object Pool. Good one.
Prototype. Good idea, but what does it have to do with OOP?
Proxy. Good one.
Singleton. It’s the king of all anti-patterns. Stay away from it at all costs.
Specification. It’s OK.
Strategy. A good one.
I have nothing against concurrency patterns either; they are all good, since they have almost nothing to do with object-oriented programming.
If you know some other design (anti-)patterns, let me know in the comments below. I’ll add them here.