Design Patterns: Factory Method Pattern

As we all well know tight-coupling or strong dependency between classes limits developer in accomodating new changes. Further extending, adding new functionality without modifying the existing code is almost impossible. Let's have a look at the simple example:

class Producer
{
public static function createConcert(genre:String):Performer
{
if(genre == "pop"){
return new BritneySpears();
}
else if(genre == "classic"){
return new Mozart();
}
}
}

There's nothing wrong with this example. It works correctly. But what if I need to add one more genre there, say "rock"? I need to add one more "if "statement and create new type of performer - rock star (or band). So, I need to alter the code, modify it to add a new type.
This considered to be a bad practice since others might use this chunk of code and you could break it while modifying it.

Design Patterns: Classes should be open for extension, but closed for modification.

In today's post I would like to go once more over the common design patterns.
With Flex framework giving its developers more and more capabilities to build really complex and large systems it becomes extremely important for the developers to know the basic and best practices of using design patterns. It is even more important when there is a group of developers working on the same project and they need to be able to understand and extend code written by their team mates. Moreover if the project has been already deployed and there is a need for its further development, software engineers should be able to extend it without modifying and breaking the existing code. This is where the design patterns come to help.
In the next posts we will cover in details some of them which, in my view, it's worth to know for every software developer.

Here's a list of patterns that commonly used these days:

• Factory Method Pattern
• Singleton Pattern
• Decorator Pattern
• Adapter Pattern
• Composite Pattern
• Observer Pattern
• Command Pattern
• State Pattern
• Strategy Pattern
• MVC Pattern
• Proxy Pattern

Not that big list, is it?
Of course that's not all. However, they cover most of the problems developers face on daily basis.
Good practical experience of using these common methods should give its users ability to build extensible classes without introducing bugs in pre-existed code and avoid tight-coupling or strong dependencies between classes.

And remember the main motto of the design patterns is: Classes should be open for extension, but closed for modification.

In the next article we're gonna be talking about Factory Method Pattern.

See you there!

Welcome to my blog! My first post.

As it's been evidenced from my last year's posting activity I am not good about the whole blogging thing. However, I'm gonna give it another try and keep posting once a week or so.

Okay, by posting here I would like to share my thoughts and experience on what I do around at work and may be some pictures of my life as well.
For those who are not familiar with what I do, I do some software development for Xponaut AB and ModularStreams Sweden.

Most of the time I work with Flex and Drupal, so posts are gonna be around these two frameworks (and languages they are written Actionscript, PHP) with occasional other stuff thrown in.
We'll have a series of discussions and analysises of implementation of common design patterns, particularly in actionscript.

Besides I am gonna be posting demo mockups of GUI of applications that I do occasionally for our customers using Xara Xtreme or Photoshop.

There are several very exciting open source projects from Google that I'm following closely. We could have a look at some of them from time to time too.

That's enough for now. Bye till next post.