Behavioral Patterns

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 19

• Behavioral Design patterns

BEHAVIORAL PATTERNS

 Command Pattern

 Chain of Responsibility
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 operation.

Command pattern is a data driven design pattern and falls


under behavioral pattern category. A request is wrapped under an
object as command and passed to invoker object. Invoker object
looks for the appropriate object which can handle this command
and passes the command to the corresponding object which
executes it.
1 2 3
Implementation
Stock class acting as request

Order acts as command

invoker
Interface Order acting as a command. Stock class
acts as a request. We have concrete classes BuyStock
and SellStock implementing Order interface which will
do actual command processing. A class Broker is
created which acts as an invoker object. It can take and
place orders.
Broker object uses command pattern to identify
which object will execute which command based on
the type of command. CommandPatternDemo, will use
Broker class to demonstrate command pattern.
Advantages and disadvantages of Command patterns:

advantages:

• It decouples the classes that invoke the operation from the object that
knows how to execute the operation.
• It allows you to create a sequence of commands by providing a queue
system.
• Extensions to add a new command is easy and can be done without
changing the existing code.
• You can also define a rollback system with the Command pattern.
 disadvantages :

• There are high no of classes and objects working together to achieve a


goal. Application developers need to be careful developing these classes
correctly.
• Every individual command is a ConcreteCommand class that increases the
volume of classes for implementation and maintenance.
Chain of Responsibility
The Chain of Responsibility creates a chain of receiver objects
for a request. This pattern decouples sender and receiver of a
request based on type of request.
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.
The chain of responsibility is an object oriented version of the
if ... else if ... else if ... else ... End if idiom, with the benefit that
the condition–action blocks can be dynamically rearranged and
reconfigured at runtime.
Implementation
Step 1 We create an abstract class AbstractLogger with a level of logging.

Step 2 We create three types of loggers extending the AbstractLogger,


namely ConsoleLogger, ErrorLogger and FileLogger

Each logger checks the level of message to its level


and prints accordingly otherwise does not print
and pass the message to its next logger.
Extends
Advantages of Chain of Responsibility Design Pattern:

• To reduce the coupling degree. Decoupling it will request the sender and
receiver.
• Simplified object. The object does not need to know the chain structure.
• Enhance flexibility of object assigned duties. By changing the members within
the chain or change their order, allow dynamic adding or deleting
responsibility.
• Increase the request processing new class of very convenient.

Disadvantages of Chain of Responsibility Design Pattern:

• The request must be received not guarantee.


• The performance of the system will be affected, but also in the code
debugging is not easy may cause cycle call.
• It may not be easy to observe the characteristics of operation, due to debug.

You might also like