Archive

Archive for June, 2014

Adapter

June 22, 2014 Leave a comment

Frequency of Use Medium – High Intent Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Structure Adapter Applicability Use the Adapter pattern when:

  • you want to use an existing class, and its interface does not match the one you need.
  • you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don’t necessarily have compatible interfaces.
  • (object adapter only) you need to use several existing subclasses, but it’s impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class

Implementation Code (C#)

using System;
public class MainClass {
 public static void Main() {
  Target target = new Adapter();
  target.Request();
 }
}

 class Target {
  public virtual void Request() {
   Console.WriteLine("Called Target Request");
  }
 }
 
 class Adapter : Target {
 private Adaptee _adaptee = new Adaptee();
 
 public override void Request() {
  _adaptee.SpecificRequest();
  }
 }
 
 class Adaptee {
  public void SpecificRequest() {
   Console.WriteLine("Called Adaptee specific Request");
  }
 }

Code Output

 Called Adaptee specific Request
Advertisements
Categories: C#, Design Pattern, Programming

Observer

June 8, 2014 Leave a comment

Frequency of Use
High

Intent
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Structure

20140608-185029-67829449.jpg

Applicability
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, and you don’t know how many objects need to be changed.
  • When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don’t want these objects tightly coupled.

 

Code Implementation (C#)

using System;
using System.Collections.Generic;

namespace Observer
{
 public class MainClass
 {
  public static void Main()
  {
    ConcreteSubject s = new ConcreteSubject();
    s.Attach(new ConcreteObserver(s, "X"));
    s.Attach(new ConcreteObserver(s, "Y"));
    s.Attach(new ConcreteObserver(s, "Z"));

    s.SubjectState = "ABCD";
    s.Notify();

    Console.ReadKey();
  }
 }

 abstract class Subject
 {
  private List<Observer> _observers = new List<Observer>();

  public void Attach(Observer observer)
  {
    _observers.Add(observer);
  }

  public void Detach(Observer observer)
  {
    _observers.Remove(observer);
  }

  public void Notify()
  {
   foreach (var observer in _observers)
   {
    observer.Update();
   }
  }
 }

 class ConcreteSubject : Subject
 {
  private string _subjectState;

  public string SubjectState
  {
    get { return _subjectState; }
    set { _subjectState = value; }
  }
 }

 abstract class Observer
 {
   public abstract void Update();
 }

 class ConcreteObserver : Observer
 {
   private string _name;
   private ConcreteSubject _subject;
   private string _observerState;

   public ConcreteObserver(ConcreteSubject subject, string name)
   {
     this._subject = subject;
     this._name = name;
   }

   public override void Update()
   {
    _observerState = _subject.SubjectState;
    Console.WriteLine("State of Observer {0} is {1}",
                      _name, _observerState);

   }

   public ConcreteSubject Subject
   {
    get { return _subject; }
    set { _subject = value; }
   }

  }
 }

Code Output

State of Observer X is ABCD 
State of Observer Y is ABCD 
State of Observer Z is ABCD
Categories: C#, Design Pattern, Programming