Design Pattern "Team" / "Command"

Read the description of other patterns.

Problem

It is necessary to have an effective presentation of requests to a certain system, while not having knowledge of their nature or of how to handle them.

Description

There are at least three motivations for using the “Team” template:

• encapsulating the request as an object for subsequent logging / logging, etc.
• endowing the entity “calling the object's method” with the properties of an independent object;
• object-oriented callback;
  ')
  
  In fact, all of the above motivations boil down to one thing - “encapsulating a request as an object” . There are a large number of types of systems where such an approach is effective and justified. First of all, this is any more serious desktop application with undo and redo user actions (undo / redo). Secondly, these are network distributed systems that use requests in the form of objects as the main primitive for initializing any operations. Third, systems with asynchronous call support encapsulate a callback in the form of a callback object. The list can be infinite, it is important to understand that the command pattern is one of the most common patterns, which, one can say, appeared literally at the stage of the establishment of the OOP and only then was formalized and described in the GoF book.
  
  The basic idea of ​​the template is to use a single interface to describe all types of operations that can be performed with the system. Then, to add support for a new operation to the system, it suffices to implement the proposed interface. Thus, each operation is represented as an independent object encapsulating some set of additional properties. The system, in turn, acquires the ability to perform an additional set of actions on requests (objects). These are logging, cancellation of the previous action, repetition of the subsequent one, etc.
  
  

  Practical example

  
  Consider the most obvious motivation for using a pattern - logging / undo-redo. To do this, imagine that it was

    <sarcasm> 

  if Stephen Bourne (by bash) had read the GoF book and knew what the “Team” design pattern is

    </ sarcasm> 

  . It would be about the following:
  
  • each shell command would be encased in a separate class — a descendant of the class Command;
  • the command shell would support logging / logging mechanisms and, most importantly, undo and redo (undo / redo) user actions, i.e. teams;
  
  
  We will try to change the problems in the design of the existing solutions and write our bike going with the possibility of canceling and repeating commands .
  
  To achieve this goal, it is enough to introduce the concept of a queue of executed commands to which any command (object, successor to Command) falls after the execution and a queue of canceled commands to which any canceled command goes. In addition, it is necessary to have separate mechanisms for executing and canceling a team’s actions. Obviously, these mechanisms are individual for each team. Then, for the implementation of a complete system, it is enough for us, in terms of two queues, to apply corresponding actions to the objects located at their apex - execution or cancellation.
  
  

  Class diagram

  
  Each command supported by the shell must extend the Command class, implementing three methods - execute (), cancel () and name () - execution, cancellation and the name of the command, respectively.
  
  The command shell class is shown only for clarity. In the above implementation, it is replaced by the main () method.
  
  
  

  Python implementation

  
  

  # -*- coding: cp1251 -*- from sys import stdout as console #   exit class SessionClosed(Exception): def __init__(self, value): self.value = value #   class Command: def execute(self): raise NotImplementedError() def cancel(self): raise NotImplementedError() def name(): raise NotImplementedError() #  rm class RmCommand(Command): def execute(self): console.write("You are executed \"rm\" command\n") def cancel(self): console.write("You are canceled \"rm\" command\n") def name(self): return "rm" #  uptime class UptimeCommand(Command): def execute(self): console.write("You are executed \"uptime\" command\n") def cancel(self): console.write("You are canceled \"uptime\" command\n") def name(self): return "uptime" #  undo class UndoCommand(Command): def execute(self): try: cmd = HISTORY.pop() TRASH.append(cmd) console.write("Undo command \"{0}\"\n".format(cmd.name())) cmd.cancel() except IndexError: console.write("ERROR: HISTORY is empty\n") def name(self): return "undo" #  redo class RedoCommand(Command): def execute(self): try: cmd = TRASH.pop() HISTORY.append(cmd) console.write("Redo command \"{0}\"\n".format(cmd.name())) cmd.execute() except IndexError: console.write("ERROR: TRASH is empty\n") def name(self): return "redo" #  history class HistoryCommand(Command): def execute(self): i = 0 for cmd in HISTORY: console.write("{0}: {1}\n".format(i, cmd.name())) i = i + 1 def name(self): print "history" #  exit class ExitCommand(Command): def execute(self): raise SessionClosed("Good bay!") def name(self): return "exit" #    COMMANDS = {'rm': RmCommand(), 'uptime': UptimeCommand(), 'undo': UndoCommand(), 'redo': RedoCommand(), 'history': HistoryCommand(), 'exit': ExitCommand()} HISTORY = list() TRASH = list() #  def main(): try: while True: console.flush() console.write("pysh >> ") cmd = raw_input() try: command = COMMANDS[cmd] command.execute() if not isinstance(command, UndoCommand) and not isinstance(command, RedoCommand) and not isinstance(command, HistoryCommand): TRASH = list() HISTORY.append(command) except KeyError: console.write("ERROR: Command \"%s\" not found\n" % cmd) except SessionClosed as e: console.write(e.value) if __name__ == "__main__": main() 

  
  
  

  Using

  
  

   $ python pysh.py pysh >> rm You are executed "rm" command pysh >> rm You are executed "rm" command pysh >> rm You are executed "rm" command pysh >> history 0: rm 1: rm 2: rm pysh >> undo Undo command "rm" You are canceled "rm" command pysh >> exit Good bay! 

  
  
  

  Note

  
  In some sources, the pattern is called Action / Action or Transaction / Transaction .