Monday, June 17, 2013

A rant on design patterns

There are few things a java programmer is expected to demonstrate after a few years of working in trenches and design patterns is cardinal to it. It is not sufficient to implement a design pattern where it is begging to be implemented, to lessen the sagging code logic and improve readability, extensibility or both but also to insert it into every nook, corner and alley of code where it might or might not serve a purpose.
I recently did a code submission for a multinational company and was rejected due to this precise reason - my code was not extensible, they said.

However, what was bitterly amusing for me was the fact that I was shipped with a document that said KISS should be followed and emphasis would be over test driven development. The main point in this frustrating experience is how can one keep it simple and stupid... or minimized without using design patterns. Either I do not have an understanding of the DPs and there is any pattern that can be used to further minimize the code, something that I did in the first place. Merely creating methods and class hierarchy to conform to a pattern(when the implementation is merely 10 lines of code) in every case seems to be an overkill, even if the code is meant to be extensible.

I think as programmer, to create a solution, there are arguably ten ways of performing a task, each with its own advantage and caveat and what is important for a programmer who is reviewing it (for recruitment or as an exercise, while merging open source changes or even for a team member) has to get this basic fundamental correct.

No comments: