Design Patterns

[The curious case of Design Patterns]

Stop creating over engineered pieces of crap. Yes, you have heard it right.

I have been working with Java for almost ten years and YES I am of the view that Design Patterns don’t add value to your project or magically improve the quality of the product. I have come across programmers/development teams focused on writing intricate classes by using design patterns with the sole intention of improving the code quality.

No, this is not how it works.

You cannot during a code-review process ask the developer to change the implementation in-order to accommodate a certain design pattern, just because you think it will improve the quality of code or will decrease the inflow of bugs.
DesignPattern-meme

I don’t think design patterns are the worst way to approach a problem, but I am completely against using them with the intention that they will improve the quality of your code. Design Patterns are not the answer to the bugs in your product.

Pattern is something that is observed or something that emerges from a certain formation. If the code is kept simple the patterns will emerge out of the code making themselves evident and obvious. So please don’t force the code in design patterns and even worst design patterns in code.

“patterns are not applied, patterns are observed”

Many young programmers also make a common mistake of confusing over-engineered code with good quality code. I have seen people who thinks merging ten lines of code in one line [which is hard to understand and debug] is quality code.
complicated over polymorphic classes != quality code

My advise to them : have fun and keep KISS-ing.

We are all enthusiastic about the code design, but let’s keep reminding ourselves the threats of over-design.

Coming back to Design Patterns, It was in the late 90’s that people in the field of programming thought that design patterns are reusable, off the shelf and complete solutions to complicated programming problems. Which turned out to be in-correct.
Design patterns are nothing but a way to communicate between experienced and mature programmers. I would stress on the word “experienced and mature” here,¬†Because one cannot sit in a discussion with the rest of the team (that comprise of all type of people) and start blabbing sentences like :

“I think we can create a Factory and a Builder here, Bridge them with an Adapter and off course add a Facade on top. Ahh.. and it would be great to make the implementation an Observer as well”

Common, admit it, we all have these certain people in our team, who think using such sentences will make them come accross as smart people and the truth is, it does. Most of the people in that discussion will buy this shit, They will go back to their desk to google these patterns and then they will somehow fit the problem in these patterns and create a solution, maybe just to prove that they are smarter.
Complicated and over-engineered code does have a tendency to make people feel smart at the end of the day.

IMHO, it is plain rude, using design patterns and advising others to do so just because we know what they are, is also not a valid or convincing reason to start using them.

The Design Patterns, as mentioned above are most useful in a situation where the team is mature enough to use them as a way of communication between them.