Command Pattern

The command pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

 

Following are some of the steps

1. Client creates Command object.

   a. Command object has execute() method

      i. Execute() method has calls to action1() and action2() methods of the Receiver object

2. Invoker object has a setCommand(Command obj) method (parameterizing an object)

3. Client calls setCommand() on the Invoker object.

4. Invoker calls execute() method of the Command object.

5. Command object then calls action1() and action2() methods of the Receiver object.

 

For example:
public interface Command {
   public void execute() ;
}

public class LightOnCommand implements Command {
   Light light;
   public LightOnCommand(Light light) {
      this. light = light;
   }
   public void execute() {
      light. on() ;
   }
}

public class SimpleRemoteControl {
   Command slot;
   public SimpleRemoteControl() { }
   public void setCommand( Command command) {
      slot = command;
   }
   public void buttonWasPressed() {
      slot. execute() ;
   }
}

public class RemoteControlTest {
   public static void main( String[ ] args) {
      SimpleRemoteControl remote = new SimpleRemoteControl() ;
   Light light = new Light() ;
   LightOnCommand lightOn = new LightOnCommand(light) ;
   remote. setCommand(lightOn) ;
   remote. buttonWasPressed() ;
   }
}

Bridge Pattern

The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently" . When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class as well as what it does vary often. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction.

  /** "Implementor" */
interface DrawingAPI {
    public void drawCircle(double x, double y, double radius);
}
/** "ConcreteImplementor" 1*/
class DrawingAPI1 implements DrawingAPI {
    public void drawCircle(double x, double y, double radius) {
       System.out.println("API1.circle at "+ x +"," +y+","+ radius);
    }
}
/** "Abstraction" */
class Shape {
    private DrawingAPI drawingAPI;
    public void draw();
}
/** "Refined Abstraction" */
class CircleShape implements Shape {
    private double x, y, radius;
    public CircleShape(double x, double y, double radius, DrawingAPI drawingAPI) {
    this.x = x; this.y = y; this.radius = radius;
    this.drawingAPI = drawingAPI;
    }
// low-level i.e. Implementation specific
    public void draw() { this.drawingAPI.drawCircle(x, y, radius); }
}
/** "Client" */
class BridgePattern {
    public static void main(String[] args) {
    Shape[] shapes = new Shape[] {
       new CircleShape(1, 2, 3, new DrawingAPI1()),
    //new CircleShape(5, 7, 11, new DrawingAPIXXX()),
    };

    for (Shape shape : shapes) {
       shape.draw();
       }
    }
}
Bridge Benefits
· Decouples an implementation so that it is not bound permanently to an interface.
· Abstraction and implementation can be extended independently.
· Changes to the concrete abstraction classes don’t affect the client.
Bridge Uses and Drawbacks
· Useful in graphic and windowing systems that need to run over multiple platforms.
· Useful any time you need to vary an interface and an implementation in different ways.
· Increases complexity.

Visitor Pattern

Visitor lets you define a new operation without changing the classes of the elements on which it operates.

// 1. accept(Visitor) interface
interface Element {
   public void accept( Visitor v ); // first dispatch
}
class ConcreteElement1 implements Element {
   String val=”hello from ConcreteElement1”;
   public void accept( Visitor v ) {
      v.visit( this );
   }
}

// 2. Create a "visitor" base class with a visit() method for every "element" type

interface Visitor {
   public void visit(ConcreteElement1 e ); // second dispatch
}
// 3. Create a "visitor" derived class for each "operation" to perform on "elements"
class ConcreteVisitor1 implements Visitor {
   public void visit(ConcreteElement1 e ) {
      System.out.println( "do concrete operation on ConcreteElement1 e" + e.val );
   }
}

// 4. Client creates "visitor" objects and passes each to accept() calls
class VisitorDemo {br>    public static void main( String[] args ) {
      ConcreteElement1 ce1= new ConcreteElement1();
      ConcreteVisitor1 cv = new ConcreteVisitor1();
      ce1.accept(cv);
   }
}
Visitor Benefits
· Allows you to add operations to a Composite structure without changing the structure itself.
· Adding new operations is relatively easy.
· The code for operation performed by the Visitor is centralized.
Visitor Drawbacks
· The Composite classes’ encapsulation is broken when the Visitor is used.
· Because the traversal function is involved, changes to the Composite structure are more difficult.