GoF book says that "Observer pattern should defina a one-to-many dependency between objects so that when one object changes state, all its dependenst are notified and updated automatically". Subscribing to RSS feeds is a nice analogy.  You subscribe to RSS feeds to show interest and you become an observer who demand for notification and RSS feeds become the subject and are responsable for providing information to all subscribers. I think this bit of information describing the pattern is enough, now lets see how we implement observer pattern.

Lets assume that we are developing a car controller software. One of the requirements is "Provide visual warning to the driver if seat belts are not locked". To meet the requirement we design

• SeatBelt class which is the subject. This class should notify interested objects about the state changes
• SeatBeltMonitor class is our observer. This class monitors for status change messages provided by the SeatBelt and displays messages

Implementing Observer Pattern in conventional way 

Download GoF_Patterns_Observer1.rar (20,36 kb)

It is suggested to specify an interface or abstract classes when dealing with patterns so that the objects we create will adhere to some predefined contract. So we start our implementation by specifying two interfaces ISubject and IObserver

C#-Code: Our interfaces

001    public interface ISubject
002    {
003        void RegisterObserver(IObserver observer);
004        void RemoveObserver(IObserver observer);
005    }
006
007    public interface IObserver
008    {
009        void Update(bool locked);
010    }

As I've mentioned above our SeatBelt class is the subject (source) of the state change and should implement the contract so that interested parties shall define their interest to the state changes More...

I believe Factory Pattern is one of the most known pattern in development community. Simply Factory Pattern states that we have a factory object which is used to create other objects. But GoF specification for the Factory Pattern is a little bit different. GoF book says that "We should define an interface for creating an object, but let subclasses decide which class to instantiate." 

How you implement the Factory Pattern depends on your custom needs. 1) If you want to control object instantiation behaviour of your factory provide a static class with static methods or sealed factory class to your clients, else 2) if you want to keep your code closed for modification but open for extension follow the GoF way by providing an interface or abstract factory class.

Method 1

Download GoF_Patterns_Factory1.rar (18,45 kb)

Now lets implement Factory Pattern for our Vehicle instantiation process so that we do not want our clients to have alternative factory implementation at all.

C#-Code: Abstract Vehicle superclass and some concrete implementations

001   //Abstract Vehicle class
002    public abstract class Vehicle
003    {
004        public abstract string Description { get; }
005    }
006    
007    //Concrete implementation
008    public sealed class Car : Vehicle
009    {
010        internal Car() { }
011        public override string Description
012        {
013            get { return "Car";}
014        }
015    }
016
017    //Concrete implementation
018    public sealed class Helicopter : Vehicle
019    {
020        internal Helicopter() { }
021        public override string Description
022        {
023            get { return "Helicopter"; }
024        }
025    }
026
027    //Concrete implementation
028    public sealed class Jet : Vehicle
029    {
030        internal Jet() { }
031        public override string Description
032        {
033            get { return "Jet"; }
034        }
035    }

I've chosen to implement my factory More...

Download Source(23,52 kb)

We have different kind of vehicle implementations inherited from an abstract Vehicle class. Our code looks like this

C#-Code: Inital version of our abstract Vehicle class and its concrete implementations

001    //Abstract Vehicle class
002    public abstract class Vehicle
003    {
004        public abstract string Description { get; }
005
006    }
007    
008    //Concrete implementation
009    public sealed class Car : Vehicle
010    {
011        public override string Description
012        {
013            get { return "Car"; }
014        }
015    }
016
017    //Concrete implementation
018    public sealed class Helicopter : Vehicle
019    {
020        public override string Description
021        {
022            get { return "Helicopter"; }
023        }
024    }
025
026    //Concrete implementation
027    public sealed class Jet : Vehicle
028    {
029        public override string Description
030        {
031            get { return "Jet"; }
032        }
033    }

Suppose that our client wants to rent these different kind of vehicles and print vehicle information plus rental specific info such as FromDate, ToDate and the customer's name. We could implement this requirement by adding those new properties to our base Vehicle class in order to meet our customer's need. We also have to modify our concrete Vehicle classes so thet they can provide rental information through their Description property.

Here is our modified Vehicle class More...

I'm sure that you have already heard at least one of the following common design/development tips

• Seperate out parts of code that will be subject to change over time from the rest of your code
• Use has-a relationship instead of is-a relationship where possible, that is prefer composition over inheritance

Strategy pattern helps us to realize these tips in our designs. By applying the Strategy Pattern we move our algorithm implementations, which are possible source of maintainance issues, away from the more stable source code.

Download

GoF_Patterns_Strategy.rar (19,76 kb)

Recommended Reading 

Design Patterns For Dummies by Steve Holzner 

Example Implementation 

In our sample scenario we have different kind of vechicles all supporting some kind of Go behaviour. More...