Skip to main content

Command Pattern

It is behavioral pattern which is used solve the problem how two object interact using the principle of abstraction to achieve certain goal.In this  pattern we have 4 main players  client ,invoker , command and receiver .

Receiver : This Object has the actual algorithm to perform the task , which is abstracted from the outer world.

Command : This Object has the reference of the Receiver class which it executes method on the receiver .

Invoker :Is aware of the command to be executed , only executes the command on the command Object.

Client : Keeps   invoker object and list of all the command objects and decides which command to execute when , client invokes the  particular command using the invoker object.

So Switch is classic case of command design pattern  ,which is invoker class and has the list of all the commands to be executed and we have command interface with a execute method now we can have two implementation of the Command interface switchON and switchOff which will call the Light Object On and Off method.Below is the sample implementation.


import java.util.List;
import java.util.ArrayList;

/** The Command interface */
public interface Command {
   void execute();
}

/** The Invoker class */
public class Switch {
   private List<Command> history = new ArrayList<Command>();

   public void storeAndExecute(final Command cmd) {
      this.history.add(cmd); // optional
      cmd.execute();
   }
}

/** The Receiver class */
public class Light {

   public void turnOn() {
      System.out.println("The light is on");
   }

   public void turnOff() {
      System.out.println("The light is off");
   }
}

/** The Command for turning on the light - ConcreteCommand #1 */
public class FlipUpCommand implements Command {
   private Light theLight;

   public FlipUpCommand(final Light light) {
      this.theLight = light;
   }

   @Override    // Command
   public void execute() {
      theLight.turnOn();
   }
}

/** The Command for turning off the light - ConcreteCommand #2 */
public class FlipDownCommand implements Command {
   private Light theLight;

   public FlipDownCommand(final Light light) {
      this.theLight = light;
   }

   @Override    // Command
   public void execute() {
      theLight.turnOff();
   }
}

/* The test class or client */
public class PressSwitch {
   public static void main(final String[] arguments){
      // Check number of arguments
      if (arguments.length != 1) {
         System.err.println("Argument \"ON\" or \"OFF\" is required.");
         System.exit(-1);
      }

      final Light lamp = new Light();
   
      final Command switchUp = new FlipUpCommand(lamp);
      final Command switchDown = new FlipDownCommand(lamp);

      final Switch mySwitch = new Switch();

      switch(arguments[0]) {
         case "ON":
            mySwitch.storeAndExecute(switchUp);
            break;
         case "OFF":
            mySwitch.storeAndExecute(switchDown);
            break;
         default:
            System.err.println("Argument \"ON\" or \"OFF\" is required.");
            System.exit(-1);
      }
   }
}

Comments

Popular posts from this blog

How to remove hardcoding .html from pathfield in AEM/CQ

In our project we have a pathfield in quite a lot of dialog for various custom components which refers/links to pages. After getting the value of this pathfield in the sightly template we were  adding the html extension manually on it. e.g.                 <a class="navbar-brand" href="${properties.homepagePath @ context='unsafe'}">${properties.headerAuthTitle}</a> We can avoid hardcoding the path by adding property in dialog link  linkPattern The  pathfield  xtype has a config option called  linkpattern . This allows you to configure the widget to automatically add an extension  in case the browsefield is used  to select the link. If a user types the text , the extension is not added. Use this option to add '.html' and all internal links will have .html appended (assuming the content authors always use the pathfield's browse option to select the link [which they should be doing ] ). This way the backend code doesn't hav

Handle bar & AEM server side integration

In AEM 6.0 version, as part of social communities’ project AEM implemented a handlebar script files in place of JSP scripts.  As part of this project AEM SCF community implemented a handle bar engine which in turn uses handlebars.java(jknack) library to compile and execute handlebar templates. Example: Let’s say I have a component called helloworld and the path of component  is  /apps/mysite/components/content/helloworld. Below three steps we need to do to implement header component. 1.       Register a HBS component To register HBS component we need to implement SocialComponentFactory interface and then we need to override methods. In “getSupportedResourceType” method we need to return component path to register it to handlebar engine.  Once we register a component json response will automatically available to handlebar script file. Example: The key aspect is to override getSocialComponent method(Resource).

Proxy Design Pattern

We use this Pattern when we require don't want to give a direct access to object under some scenario and rather offer a surrogate object  or proxy object which  provides the functionality in place of the real object. There could be several scenario where we would want this kind of functionality. The  real object  has some sensitive operation which would be risky to expose. The real object creation is memory extensive so we want to control the behavior of its creation. The real object is remotely located and rather we want to interact through a local copy using proxy which is actually   aware of it location. So lets look at the UML diagram of the same. So here we have Subject interface which is implemented by both the Proxy and RealObject  and proxy object has  reference to the real object , now the client will  instantiate Proxy object to perform some action and , proxy object will delegate the call to RealSubject to perform the same.