Archive for the ‘Design Patterns’ Category

Learn this: Strategy pattern vs Decorator pattern

May 10th, 2009

As mentioned in a previous article, one thing I like to do when giving interviews is throwing out a curve ball. A standard type of questions I like to ask about are design patterns. Normally I will ask them to describe a specific pattern and seeing that both Strategy patterns and Decorator patterns are pretty common, I will ask about those. Most of the time, they can answer at least one of those. Whenever they answer both, I like to throw in the ‘Describe the difference between them and when you would use them.’

I ask this normally because it is kind of a gray area. Well maybe gray area isn’t the correct phrase, but they are strikingly similar*. They both encapsulate and delegate the behavior of the classes. They both encourage composition. Both are great alternatives to inheritance. And they both allow for new behaviors to be easily added to existing classes. With all the similarities, its hard to see where they differ, making it a great question to ask in an interview.
Read more…

Best Practices, Design Patterns, Learn This, Opinion, tutorial , , , ,

The importance of Composition

February 4th, 2009

Many times when we are designing our programs model, first thing most people, including myself, want to start doing is inheriting from other classes. This makes for a nice large hierarchical beast. Not that there is anything wrong with that, but it can lead to certain problems (from my own personal experience, it usually does). With composition, the programmer no longer has to extend from the parent class. You are able to expose only the methods you are interested in. In this article, I really want to discuss the importance of composition. I feel as programmers, many of us find inheritance easier and we often use it without thinking about the repercussions it may bring to us.
Read more…

Best Practices, Design Patterns, Opinion, Random Notes , ,

Template Pattern

April 29th, 2008

In this article I want to discuss the Template Pattern. One of the main reasons why I wanted to talk about it is that it holds a few similarities to the Strategy Pattern (which I recently wrote an article on). At the end of this article, I will discuss the differences between the two in hopes to help you choose what fits best for you.

So what is a Template pattern? A Template is a way for use to define the skeleton of an algorithm in an abstract class. The skeleton for our algorithm is defined within a final method, so the outline cannot change. How these methods are carried out are then defined within the subclasses. When used, it gives an inverted control structure, where the super class calls the subclasses methods. This is also how it became known as the Hollywood Method, or “Don’t call us, We’ll call you.”. So lets take a closer look.
Read more…

Design Patterns

How and when to use Singleton classes

April 20th, 2008

It’s a pretty well known pattern, but I want to discuss what a Singleton class is first. In a nutshell, a Singleton class is a class that will only have one instance of the class. In certain cases, we want to make sure that we cannot instantiate multiple copies of the object, so we limit it to just one copy. Instead of having a public constructor for our class, we use a private constructor. Then we use a public method (usually named getInstance()) to make sure there is only one copy.
Read more…

Best Practices, Design Patterns

The Strategy Pattern

April 18th, 2008

I will get right to the point about this pattern. Everyone at some point in their code has a switch statement, that depending on the state of an object, you do some crap and it just looks like this:

   case Type1:amount=something;break;
   case Type2:amount=somethingelse;break;
   case Type3:etcetcetc;

Read more…

Design Patterns