Behavioral Design Pattern Behavioral patterns are concerned with

Behavioral Design Pattern

Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects. Behavioral patterns describe not just patterns of objects or classes but also the patterns of communication between them. These patterns characterize complex control flow that's difficult to follow at run-time. They shift your focus away from flow of control to let you concentrate just on the way objects are interconnected. Behavioral class patterns use inheritance to distribute behavior between classes.

Chain of Responsibility

As the name suggests, the chain of responsibility pattern creates a chain of receiver objects for a request. This pattern decouples sender and receiver of a request based on type of request. This pattern comes under behavioral patterns. In this pattern, normally each receiver contains reference to another receiver. If one object cannot handle the request then it passes the same to the next receiver and so on. Example: ATM(rupees of 1000, 500, 100 etc)

Intent Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Motivation Consider a context-sensitive help facility for a graphical user interface. The user can obtain help information on any part of the interface just by clicking on it. The help that's provided depends on the part of the interface that's selected and its context; for example, a button widget in a dialog box might have different Help information than a similar button in the main window. If no specific help information exists for that part of the interface, then the help system should display a more general help message about the immediate context—the dialog box as a whole

Applicability Use Chain of Responsibility when Ø more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically. Ø you want to issue a request to one of several objects without specifying the receiver explicitly. Øthe set of objects that can handle a request should be specified dynamically.

Participants ØHandler (Help Handler) o defines an interface for handling requests. ØConcrete. Handler (Print. Button, Print. Dialog) o handles requests it is responsible for. Ø Client o initiates the request to a Concrete. Handler object on the chain.

Collaborations Ø When a client issues a request, the request propagates along the chain until a Concrete Handler object takes responsibility for handling it. Consequences Chain of Responsibility has the following benefits and liabilities: §Reduced coupling. §Added flexibility in assigning responsibilities to objects. Chain of Responsibility gives you added flexibility in Distributing responsibilities among objects.

Implementation We have created an abstract class Abstract. Logger with a level of logging. Then we have created three types of loggers extending the Abstract. Logger. Each logger checks the level of message to its level and print accordingly otherwise does not print and pass the message to its next logger.

Step 1 Create an abstract logger class. Abstract. Logger. java public abstract class Abstract. Logger { public static int INFO = 1; public static int DEBUG = 2; public static int ERROR = 3; protected int level; //next element in chain of responsibility protected Abstract. Logger next. Logger; public void set. Next. Logger(Abstract. Logger next. Logger) { this. next. Logger = next. Logger; }

public void log. Message (int level, String message) { if(this. level <= level) { write(message); } if(next. Logger !=null) { next. Logger. log. Message(level, message); } } abstract protected void write(String message); }

Step 2 Create concrete classes extending the logger. Console. Logger. java public class Console. Logger extends Abstract. Logger { public Console. Logger(int level) { this. level = level; } @Override protected void write(String message) { System. out. println("Standard Console: : Logger: " + message); } }

Error. Logger. java public class Error. Logger extends Abstract. Logger { public Error. Logger(int level) { this. level = level; } @Override protected void write(String message) { System. out. println("Error Console: : Logger: " + message); } }

File. Logger. java public class File. Logger extends Abstract. Logger { public File. Logger(int level) { this. level = level; } @Override protected void write(String message) { System. out. println("File: : Logger: " + message); } }

Step 3 Create different types of loggers. Assign them error levels and set next logger in each logger. Next logger in each logger represents the part of the chain. Chain. Pattern. Demo. java public class Chain. Pattern. Demo { private static Abstract. Logger get. Chain. Of. Loggers() { Abstract. Logger error. Logger = new Error. Logger(Abstract. Logger. ERROR); Abstract. Logger file. Logger = new File. Logger(Abstract. Logger. DEBUG); Abstract. Logger console. Logger = new Console. Logger(Abstract. Logger. INFO); error. Logger. set. Next. Logger(file. Logger); file. Logger. set. Next. Logger(console. Logger); return error. Logger; }

public static void main(String[] args) { Abstract. Logger logger. Chain = get. Chain. Of. Loggers(); logger. Chain. log. Message(Abstract. Logger. INFO, "This is an information. "); logger. Chain. log. Message(Abstract. Logger. DEBUG, "This is a debug level information. "); logger. Chain. log. Message(Abstract. Logger. ERROR, "This is an error information. "); } }

Step 4 Verify the output. Standard Console: : Logger: This is an information. File: : Logger: This is a debug level information. Standard Console: : Logger: This is a debug level information. Error Console: : Logger: This is an error information. File: : Logger: This is an error information. Standard Console: : Logger: This is an error information.