Template Method Design Pattenr

Template method design pattern more useful after observer, visitor, command, factory, decorator , single tone and of course facade and adapter :-))), but anyway I think it very nice and not so simple to understand.
Those two reasons, why I would like show this pattern in VERY simple way, I hope it will helps understand this pattern in couple of minutes:

OK, first of all short explanation:

Suppose, we want to prepare for us and tea for friend. We will boil water and after put coffee and tea into the cups. So, we will perform 4 actions:

1. - boil water and put into the cup_1
2. - boil water and put into the cup_2
3. - put coffee into the cup_1
4. - put tea into the cup_2

We have 4 methods and 2 same actions at all (1&2)

So, we can create template method for 1 & 2.
OK, Lets see some code in order to understand it simple:

using System;
 
namespace TemplateMethodPattern
{
    class Program
    {
        static void Main(string[] args)
        {
            var tea = new Tea();
            tea.Create();
 
            var cofee = new Cofee();
            cofee.Create();
 
            Console.ReadLine();
        }
    }
 
    public abstract class TemplateCreateDrink
    {
        public void Create()
        {
            BoilWater();
            AddSomethink();
        }
 
        public void BoilWater()
        {
            Console.WriteLine("Boil Water");    
        }
 
        public abstract void AddSomethink();
    }
 
    public class Tea: TemplateCreateDrink
    {        
        public override void AddSomethink()
        {
            Console.WriteLine("Add Tea to Water");
        }
    }
 
    public class Cofee : TemplateCreateDrink
    {
        public override void AddSomethink()
        {
            Console.WriteLine("Add Cofee to Water");
        }
    }    
}

And...we create template pattern in order to prepare tea and coffee :)

Software Basic Architecture

In this post I would like to explain some basic software architecture. If you going to build your new application from scratch and you decide to build application that will be right OO designed, following architecture can helps you in.

Doesn't matter, you going to build Winform, WPF or Web application the basic architecture still to be same.

Before you going to read this post, I suggest you to be familiar with Dependency Injection (see my previous posts) and MVC and / or MVVM pattern.

1. Represents Client View - it's may be HTML, WPF or Winform application. This part of application not so 'interesting' for us and not an issue in this post. After some interaction accured with user and request has been sent to the server (in case of Web application) we suppose to come to Controller / CommandHandler or some else object that responsible to get response from client and decide what going on with. Let's take example of currency calculator. In this case we got some data model from client, like: 

Pseudo Code:

class CurrencyModel:

{

     string currencyCodeFrom = 'USD', 

     string currencyCodeTo = 'EUR'

     decimal quantityToConvert = 100.0

     decimal quantityAfterConversion = 0.0

}

OK, we have our first model, that arrived to  our first layer (number 3 on pic.1)

First of all we would like to save current state of our main model, before we going to change it or may be not, any way. 

We need to create DataModelManager that will holds all Models that inherit from  IMainCurrencyModel that inherit from IDataModel interface all application session or until we will delete it from. 

MainCurrencyModel has method Update(CurrencyModel currencyModel):

class MainCurrencyModel

{

     public CurrencyModel _currencyModel {get; set;}

     Update(CurrencyModel currencyModel)

     {

           _currencyModel = currencyModel;

     }

}

So, now we have data to going on to service. Now we need to get service provider in order to refer to service and get back quantityAfterConversation. Suppose,  service wait from us currencyCodeFrom, currencyCodeTo and  quantityToConvert and after perform all works for us return us in response quantityAfterConversion.

OK, let's assume that we have two service providers (or maybe more) of currency conversions rates. In this case we don't want create service provider with 'new' and we will user service manager build for us list of all service providers we have define in our application scope and let to Business Logic to decide which one to use.

While creating service provider object we must inherit from IServiceProvider. While application starts ServiceManager running and imports [imports many] all objects inherits from IServiceProvider (using MEF dependancy injection framework).

Now we need get from a list of providers one we need to use in our case, let's say we will use 'ChippestConversionServiceProvider':

pseudo code:

//let's save our current DataModel

var mainDataModel = DataModelManager<MainDataModel>();

mainDataModel.Update(CurrencyModel);

//get our serviceProvider we need according our Business Logic 

var serviceProviders = ServiceManager.GetServiceProvider<ChippestConversionServiceProvider>();

serviceProvider.GetQuantityAfterConversion(mainDataModel );

In case you need to use another serviceProvider you can take from all list of serverProviders:

var serviceProviders = ServiceManager.GetServiceProvider();

provider you need to use according to specific logic:

Example:

if(currencyCodeFrom  == 'USD')

   var serviceProvider = serviceProvider.Where(x=>x.GetType == 'ChippestConversionServiceProvider')

else

  var serviceProvider = serviceProvider.Where(x=>x.GetType == 'RapidConversionServiceProvider')

Of course all providers must realize GetQuantityAfterConversion() method.

OK, we finished explanation of 3,4,9 parts of pic. 1

To be continued :-)

Factory Method Pattern

Very useful pattern, that I am using almost each day - Factory Method Pattern.
I would like to explain it with very simple code that I created for this post:

Before just to image how its looks:



C# Code:

3 Instances that will need to create according to some conditions and we did know before:

 public class Instance1: IInstance
    {
        public void Print()
        {
            Console.WriteLine(ToString());
            Console.ReadLine();
        }
    }

 public class Instance2: IInstance
    {
        public void Print()
        {
            Console.WriteLine(ToString());
            Console.ReadLine();
        }
    }


 public class Instance3: IInstance
    {
        public void Print()
        {
            Console.WriteLine(ToString());
            Console.ReadLine();
        }
    }

All this instances inherits from IInstance interface that have only one PRINT(); method:


 public interface IInstance
    {
        void Print();   
    }

Next - its a Factory class that do all works (concrete of IFactory interface), create one of three above Instance classes according to some condition, in our case its simply swithch caseindex.


 public interface IFactory
    {
        IInstance CreateInstance();
    }




 public class Factory: IFactory
    {
        private int Index { get; set; }
 
        public Factory(int instanceIndex)
        {
            Index = instanceIndex;
        }
        public IInstance CreateInstance()
        {
            switch (Index > 2 ? 3 : Index)
            {
                case 1:
                    return new Instance1();                    
                case 2:
                    return new Instance2();
                default:
                    return new Instance3();
            }
        }        






and, main that will run our modest programm:


 static void Main(string[] args)
 {
      IInstance instance = new Factory(2).CreateInstance();
      instance.Print();
 }


Enjoy!

Observer Pattern with Managed Extensibility Framework (MEF)

Following example expose using of Observer Pattern with MEF dependency injection.
I will need send to all observers XmlElement I got from WebService.

Interfaces of Observer Pattern:

public interface IResponceObserver
{
        void Update();
}

public interface IResponceSubject
{
        List<IResponceObserver> Observers { get; set; }
        void Attach(IResponceObserver observer);
        void Detach(IResponceObserver observer);
        void Notify();
}

And Concrete of Subject interface:

public class ResponceSubject: IResponceSubject
{
        public List<IResponceObserver> Observers { get; set; }
        
        public void Attach(IResponceObserver observer)
        {
            Observers.Add(observer);
        }
 
        public void Detach(IResponceObserver observer)
        {
            Observers.Remove(observer);
        }
 
        public void Notify()
        {
            foreach (IResponceObserver o in Observers)
            {
                o.Update();
            }
        }
}

Suppose we have two observer classes that need to realize Update() method:

[Export(typeof(IResponceObserver))]
public class LoginCommandHandler_1 : CommandHandlerBase, IResponceObserver
{

     public void Update()

     {

        WriteLine ("LoginCommandHandler_1")

     }

}

[Export(typeof(IResponceObserver))]
public class LoginCommandHandler_2 : CommandHandlerBase, IResponceObserver
{
     public void Update()
     {
        WriteLine ("LoginCommandHandler_2")
     }
}

And Main Class that will add observer to List of subject and Notify all observers:

public class CustomerServiceAgent : ICustomerServiceAgent
{         
        [ImportMany]
        public IResponceObserver[] ResponseObservers { get; set; }

        public void SomethingDo()
        {
            //REGISTER ALL OBSERVERS WHO WANT TO GET ANY FROM response.Customer
            IResponceSubject responceSubject = new ResponceSubject();
            foreach (var observer in ResponseObservers)
            {
                responceSubject.Attach(observer);   
            }            
 
            //YOUR CODE HERE:
            //UPDATE All Observers with response.Customer.Any
            responceSubject.Notify();
 
            return customer;
        }
}

Output:

\> LoginCommandHandler_1
\> LoginCommandHandler_2

I hope its help to understand MEF and return against on Observer Pattern


Thanks,
Enjoy! 

Explicit Interface C#

In this article we will see how to explicitly implement interface members and how to access those members from the interface instances.
 

One of the challenges we face with interfaces is that they may include that have the same name as existing class member or any other interface that you may be implementing. Hence we use explicit interface implementation to distinguish the interface methods that would otherwise conflict. When a member is explicitly implemented, it cannot be accessed through a class instance, but only through an instance of the interface.
 

Let us look at an example where we have two interfaces and we will implement the same in our class:
 

interface Interface1
    {
        void InterfaceMethod();
    }

    interface Interface2
    {
        void InterfaceMethod();
    }

    class MyClass : Interface1, Interface2
    {
        public void InterfaceMethod()
        {
            Console.WriteLine("MyClass.InterfaceMethod()");
        }
    }
In this case, InterfaceMethod is a public class member that implicitly implements a member of both interfaces. InterfaceMethod() can be invoked through either interface or through the class itself as follows:
 

MyClass mclass = new MyClass();
Interface1 minterface1 = (Interface1)mclass;
Interface2 minterface2 = (Interface2)mclass;

minterface1.InterfaceMethod();
minterface2.InterfaceMethod();
mclass.InterfaceMethod();
 

The output from this code is:
 

MyClass.InterfaceMethod()
MyClass.InterfaceMethod()
MyClass.InterfaceMethod()
 

This works fine if you want InterfaceMethod() to do the same thing in both interfaces. But in real scenarios methods which are in different interfaces have unique purpose and implementation, so here we will see the implementation of Explicit interface by just using its fully qualified name.
 

Let change our MyClass code a little like the one below:
 

class MyClass : Interface1, Interface2
    {
        public void InterfaceMethod()
        {
            Console.WriteLine("MyClass.InterfaceMethod()");
        }

        void Interface1.InterfaceMethod()
        {
            Console.WriteLine("Interface1.InterfaceMethod()");
        }
    }
 

Now when we run our application we get the following output:

Interface1.InterfaceMethod()
MyClass.InterfaceMethod()
MyClass.InterfaceMethod()

 

Remember that when an interface method is explicitly implemented, we cannot access that as a public member of the class. The only way to access it is through the interface.
 

Lets modify the MyClass to check this:
 

class MyClass : Interface1, Interface2
    {
        void Interface1.InterfaceMethod()
        {
            Console.WriteLine("Interface1.InterfaceMethod()");
        }
    }
 

Let's run our program and check the output:
 

We get a compile error:
 

MyClass does not contain a definition for 'InterfaceMethod' and no extension method 'InterfaceMethod' accepting a first argument of type MyClass could be found (are you missing a using directive or an assembly reference?
 

We get this error because the explicit implementation of Interface1.InterfaceMethod()
 

hides from the class. The only way to call Interface1.InterfaceMethod() now is through MyClass minterface1 interface.
 

Let's look at an example where we want to call default methods and implement the methods normally from one interface, and explicitly implement the methods from another interface:
 

MyClass implementation is changed to show this example:
 

interface Celsius
    {
        void GetTemp();
    }

    interface Fahrenheit
    {
        void GetTemp();
    }

class MyClass : Celsius,Fahrenheit
    {
        public void GetTemp()
        {
            Console.WriteLine("Get Celsius Temp");
        }

        void Fahrenheit.GetTemp()
        {
            Console.WriteLine("Get Fahrenheit Temp");
        }
    }
 

In this case, you can access the Celsius GetTemp from the class instance and access the Fahrenheit  GetTemp from the interface instance:
 

MyClass mclass = new MyClass();
Fahrenheit mfahrenheit  = (Fahrenheit)mclass;

mclass.GetTemp();
mfahrenheit.GetTemp();
 

Following is the output in the above case:
 

Get Celsius Temp
Get Fahrenheit Temp
 

Hope you liked this article.
 

Coder-Forever!

Visitor Design Pattern

In Simple words - In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to easily follow the open/closed principle.


UML:



The participants classes in this pattern are:

• Visitor - This is an interface or an abstract class used to declare the visit operations for all the types of visitable classes. Usually the name of the operation is the same and the operations are differentiated by the method signature: The input object type decides which of the method is called.

• ConcreteVisitor - For each type of visitor all the visit methods, declared in abstract visitor, must be implemented. Each Visitor will be responsible for different operations. When a new visitor is defined it has to be passed to the object structure.

• Element- is an abstraction which declares the accept operation. This is the entry point which enables an object to be "visited" by the visitor object. Each object from a collection should implement this abstraction in order to be able to be visited.

• ConcreteElement - Those classes implements the Visitable interface or class and defines the accept operation. The visitor object is passed to this object using the accept operation.

A user object receives a pointer to another object which implements an algorithm. 





The visitor pattern is used when:

• Similar operations have to be performed on objects of different types grouped in a structure (a collection or a more complex structure).

• There are many distinct and unrelated operations needed to be performed. Visitor pattern allows us to create a separate visitor concrete class for each type of operation and to separate this operation implementation from the objects structure.

• The object structure is not likely to be changed but is very probable to have new operations which have to be added. Since the pattern separates the visitor (representing operations, algorithms, behaviors) from the object structure it's very easy to add new visitors as long as the structure remains unchanged.

The Observer Pattern

With this post I opening my new posts line of Design Patterns.
And First one, I think, important one - Observer Pattern.
I really hope I'll possible explain pattern in easy and understandable way.
Enjoy :-)

Why to use:

The need to maintain consistency between related objects without making
classes tightly coupled.

When to use:


Use the Observer pattern in any of the following situations:
- When an abstraction has two aspects, one dependent on the other.
   Encapsulating these aspects in separate objects lets you vary and reuse
   them independently.
- When a change to one object requires changing others
- When an object should be able to notify other objects without making
   assumptions about those objects

Participants:
Subject

• Keeps track of its observers
• Provides an interface for attaching and detaching Observer objects

Observer

• Defines an interface for update notification

ConcreteSubject

• The object being observed
• Stores state of interest to ConcreteObserver objects
• Sends a notification to its observers when its state changes

ConcreteObserver

• The observing object
• Stores state that should stay consistent with the subject's
• Implements the Observer update interface to keep its state consistent with the subject's

Benefits

Minimal coupling between the Subject and the Observer

• Can reuse subjects without reusing their observers and vice versa
• Observers can be added without modifying the subject
• All subject knows is its list of observers
• Subject does not need to know the concrete class of an observer, just that each observer implements the update interface
• Subject and observer can belong to different abstraction layers

Support for event broadcasting

• Subject sends notification to all subscribed observers
• Observers can be added/removed at any time

Consequences

Liabilities

• Possible cascading of notifications
• Observers are not necessarily aware of each other and must be careful about triggering updates
• Simple update interface requires observers to deduce changed item

Implementation Issues

How does the subject keep track of its observers?

• Array, linked list

What if an observer wants to observe more than one subject?

• Have the subject tell the observer who it is via the update interface

Who triggers the update?

• The subject whenever its state changes
• The observers after they cause one or more state changes
• Some third party object(s)

Make sure the subject updates its state before sending out notifications

How much info about the change should the subject send to the observers?

• Push Model - Lots
• Pull Model - Very Little

Can the observers subscribe to specific events of interest?

• If so, it's publish-subscribe

Can an observer also be a subject?

• Yes!

What if an observer wants to be notified only after several subjects have

changed state?

• Use an intermediary object which acts as a mediator
• Subjects send notifications to the mediator object which performs any necessary processing before notifying the observers.

Known Uses

Smalltalk Model/View/Controller user interface framework

• Model = Subject
• View = Observer
• Controller is whatever object changes the state of the subject

Related Patterns

• Mediator

              › To encapsulate complex update semantics.

And now, some thing you are waiting for....code sample :-)

Observable Class:

public Observable()
 Construct an Observable with zero Observers
public synchronized void addObserver(Observer o)
 Adds an observer to the set of observers of this object
public synchronized void deleteObserver(Observer o)
 Deletes an observer from the set of observers of this object
protected synchronized void setChanged()
 Indicates that this object has changed
protected synchronized void clearChanged()
 Indicates that this object has no longer changed, or that it has already
 notified all of its observers of its most recent change.  This method is called
 automatically by notifyObservers().

public synchronized boolean hasChanged()
 Tests if this object has changed.  Returns true if setChanged() has been
 called more recently than clearChanged() on this object; false otherwise.
public void notifyObservers(Object arg)
 If this object has changed, as indicated by the hasChanged() method, then
 notify all of its observers and then call the clearChanged() method to
 indicate that this object has no longer changed.  Each observer has its
 update() method called with two arguments: this observable object and the
 arg argument. The arg argument can be used to indicate which attribute of
 the observable object has changed.
public void notifyObservers()
 Same as above, but the arg argument is set to null.  That is, the observer is
given no indication what attribute of the observable object has changed.

Observer Interface

public abstract void update(Observable o, Object arg)
 This method is called whenever the observed object is changed. An
 application calls an observable object's notifyObservers method to have all
 the object's observers notified of the change.
 Parameters:
   › o - the observable object
   › arg - an argument passed to the notifyObservers method

-------------------------------------------------------------------------------------------------------


/**
 * A subject to observe!
 */
public class ConcreteSubject extends Observable
{
  private String name;
  private float price;

  public ConcreteSubject(String name, float price)
  {
    this.name = name;
    this.price = price;
    System.out.println("ConcreteSubject created: " + name + " at "
      + price);
  }

  public String getName() {return name;}
  public float getPrice() {return price;}

  public void setName(String name)
  {
    this.name = name;
    setChanged();
    notifyObservers(name);
   }

  public void setPrice(float price)
  {
    this.price = price;
    setChanged();
    notifyObservers(new Float(price));
  }
}

----------------------------------------------------------------------------------------------------


An observer of name changes.
public class NameObserver implements Observer
{
  private String name;
  public NameObserver()
 {
    name = null;
    System.out.println("NameObserver created: Name is " + name);
  }
  public void update(Observable obj, Object arg)
  {
    if (arg instanceof String)
    {
      name = (String)arg;
      System.out.println("NameObserver: Name changed to " + name);
    }
    else
    {
      System.out.println("NameObserver: Some other change to subject!");
     }
   }
}

// An observer of price changes.
public class PriceObserver implements Observer
{
  private float price;
  public PriceObserver()
  {
    price = 0;
    System.out.println("PriceObserver created: Price is " + price);
  }
  public void update(Observable obj, Object arg)
  {
    if (arg instanceof Float)
    {
      price = ((Float)arg).floatValue();
      System.out.println("PriceObserver: Price changed to " + price);
    }
    else
    {
      System.out.println(”PriceObserver: Some other change to subject!");
    }
  }
}

----------------------------------------------------------------------------------------------------

// Test program for ConcreteSubject, NameObserver and PriceObserver
public class TestObservers
{
    public static void main(String args[])
    {
        // Create the Subject and Observers.
        ConcreteSubject s = new ConcreteSubject("Corn Pops", 1.29f);
        NameObserver nameObs = new NameObserver();
        PriceObserver priceObs = new PriceObserver();
        // Add those Observers!
        s.addObserver(nameObs);
        s.addObserver(priceObs);
        // Make changes to the Subject.
        s.setName("Frosted Flakes");
        s.setPrice(4.57f);
        s.setPrice(9.22f);
        s.setName("Sugar Crispies");
    }
}

Test program output
    ConcreteSubject created: Corn Pops at 1.29
    NameObserver created: Name is null
    PriceObserver created: Price is 0.0
    PriceObserver: Some other change to subject!
    NameObserver: Name changed to Frosted Flakes
    PriceObserver: Price changed to 4.57
    NameObserver: Some other change to subject!
    PriceObserver: Price changed to 9.22
    NameObserver: Some other change to subject!
    PriceObserver: Some other change to subject!
    NameObserver: Name changed to Sugar Crispies