Patronize Patternize

Patterns, Patterns, Patterns -- that's what I have been doing the last couple of days...This was in preparation to a "OO Design Pattern" test that my organization wanted me to take when I moved to a new position. Being a self-proclaimed OO expert, I couldn't take a chance of doing badly in the test, so literally went on a pattern hunt and the jungle I found there was more dense than the Amazon!

Design Patterns were available only in "dozens" which made me squirm with disbelief...Nothing against GoF, but they seem to have summarized every observation of theirs into a pattern which just added to the "overload" from a quiz perspective. Even Null Object, Debug were patterns! I thought they were "basic" concepts...giving them the 'pattern' name was just an overkill...Reminds me of the patterns inside our company that we have...We have a "pattern template" which is a pattern to write patterns...Can anything get more ludicrous?

Patterns were patterned (read conceptualized) to give our code structure, readability and extensibility...Many would put extensibility over structure and readability, but I think otherwise. In the 10 years I have been in this software world, I have seen very few instances where we really extended our initial codebase..On the other hand, I have been thrown around in projects and have had to pick them up in no time in no time...Readability and Structure I have seen have been very useful in getting me up to speed with the projects more than my ability to recognize patterns in code...Infact, sometimes patterns even obscure your code and almost make it un-understandable. Imagine mapping six classes or more to come to the real implementation in your head..I am not stretching my imagination here...these are situations that I have encountered and situations I hate. When I fall on a wrong trail, I have to retrace my many steps and start all over again..Not a pretty exercise.

Patterns were meant to simplify a coders life..so if you are complicating truth and life by hiding it behind layers of patterns, it might not be the best way to write code. And also, calling every bloody damn thing we see in this world is not a good PATTERN!! Maybe, we should represent GoF as Gang of Five (me being the latest addition)..Good Pattern?

I like Singleton, Proxy, Facade, Factory, Bridge, Observer, Cache and Command. I think everything else is a derivative or is just not necessary!!

Labels: , ,


At 6:31 PM, Anonymous Anonymous said...

IOC is a powerful concept that stemmed from the Strategy Pattern. I like this pattern a lot and I don't think that this is a ludicrous derivative of the patterns list you mentioned.

The beauty of patterns lies in the fact that they are situational. If you are in a particular situation then a particular approach (pattern) is most suitable (time tested, heavily optimized by observation etc) to solve it (of course there will be exceptions).

If we just want to read up all the patterns without having a context in mind, it will be difficult to appreciate as we lack the perspective.

At 4:17 PM, Blogger Vijay Challa said...

This comment has been removed by the author.

At 4:44 PM, Blogger Vijay Challa said...

I agree. I love the strategy pattern too, but just because I like it, I shouldn't structure my code around it. If it suits the context, one should! But, mindless application of patterns just for the sake of using it is not right.

In fact, most patterns make perfect sense when used in building application frameworks, plug-n-play (reusable) components because the basic intent there is usage and easy configurability. IoC and MVC are perfect examples for the same.

Patronizing patterns(meant over-usage actually :)) of patterns is never too good.

When developing something, one must bring context into perspective. A few good questions can be :
1) What is my intended audience?
2) How will they interact with my application?
3) How extendible should my system be? (Frameworks have to be verryy flexible..else, we can just call them apps :)
4) Who is going to maintain my system...A VERY IMPORTANT QUESTION.

App frameworks and business apps are totally different beasts. App frameworks have to be extendable/extensible by nature. Business apps have to extensible too, but that probably comes a little lower on the stack...they have to be usable and maintanable first :)


Post a Comment

Links to this post:

Create a Link

<< Home