Friday, May 15, 2009

Example Code, Patterns and OOD

So, I've titled this post a couple of times now and each time I reverse the order of the concepts. I apologize if it turns out to be backwards in the final draft and it throws the more inflexible of you for a loop.  Moving on...

I've noticed a few things about developers that I've worked with during my career. When creating solutions to problems there are three common plans of attack they follow: they grab a piece of someone else's code from somewhere and shoe horn it in, they find a design pattern that more or less works for the problem at hand, or they think about the problem from an OOD perspective and plan out the code to come.

Example code sometimes gets a job done.  But it was originally written for someone else's job.  If this is always the course of action taken, there is a greater likelihood that the code will not mesh with the architecture or surrounding code that is already in place.

Design patterns are better.  They force you to think about the problem abstractly.  Then you can write code around them that both solves the problem and fits the architecture of your application.  However, at the core, they are still based on a design that is meant to be implemented in a particular way.  Sure there are enough design patterns out there to satisfy any need, but do you really want to memorize them all?

Knowing your object oriented design concepts is definitely the way to go; encapsulation, inheritance and polymorphism.  There is no design pattern I have seen that can not be boiled down to a combination of different amounts of these concepts.  If you know how to use each of them, there are no problems you can't solve and your code will fit into any architecture and follow whatever conventions you need it to.

Admittedly, sometimes you just need to know how to add a particular CSS class to the fifth paragraph tag on a web page using JavaScript.  For that, a code example will definitely get you going in the right direction fastest.  And design patterns are excellent for instruction and communication.  How better to learn when to use the different design principles than by example.  And naming a properly chosen design pattern can save a lot of time when conveying the solution of a complex problem.  

But I feel that by considering a problem from an object oriented perspective first you will end up with the best solution most often.  Sometimes the best solution will turn out to be based on one of the other two tactics.  But this way, you know you arrived at the right one.

No comments:

Post a Comment