Ahh.. Just finished a design revamp task at my work and I think coffee is a good idea this time, also best time to write my first post here.. 🙂
Let me ask you, what do you think about the flow diagram below ?
Left most image is often called "spaghetti wiring mess" , second one is an "organized and labelled wiring" and last two are the SAP icons for 'Code' and 'Coffee' respectively. Obviously I am at the last stage in this flow ! So let me explain a little bit about 'Code' while having this 'Coffee'.
Developing software is fun for coding enthusiasts. It is indeed a lot of fun for experimentation, however when customers pay you for the software you create and maintain, it is a lot of responsibility on the designers and developers to deploy solution without causing maintenance nightmares. This is when the design patterns becomes very handy !
Design Patterns
Design patterns are primarily techniques envisaged by much experienced developers in order to solve common design problems in most efficient way by improving re-usability, maintainability, readability and extensibility of the software. There are many design patterns most developers are familiar with to name a few are - MVC , Factory, Singleton, Observer , Decorator etc. Today I will talk about Chain of Responsibility (CoR) pattern with a use case. Before we start, let me briefly touch upon the widely acclaimed principles in the OO design known as - S.O.L.I.D principles introduced by Robert C Martin (Uncle Bob) .
SOLID Principles
Each letter in 'SOLID' represent one principle as explained below -
With these principles in mind, let's look at the pattern and the code
CoR Pattern Basics
In CoR pattern a request from caller is propagated through a chain of handlers in which the relevant handlers perform a task in response and calls next handlers until chain is ended.
All request handler classes are derived from a common interface each implementations shall have the handler methods with unique business logic to perform an action.
The reference to next handler instance in the chain is stored in a private variable within each object
CoR pattern is most applicable in the following cases -
Use Case
Let's say there is a requirement to trigger communication via various channels (email, sms, fax etc.) to business partners . Which channels are needed to be determined at runtime. Adding a new communication channel need to be plug-and-play with optimal testing required and no re-testing for other existing channels. It should be flexible to switch on/off a particular channel communication globally. Adding a new template of message (say new email message format) need to be quick and to be carried out with minimum testing required.
There are different ways to trigger messages, customize message templates etc. in ECC and S/4 by standard. But lets look at it from a custom abap development perspective this time.
How to fit this requirement to CoR pattern?
The crux of the design is an interface say request handler interface as explained above and all the handlers need to implement this interface. We can use factory pattern to instantiate each handler and all the handler classes need to be chained by adding reference to subsequent handlers in the private attribute.
Code Snippets
CoR Request handler interface
CoR Email handler factory
CoR Email handler (Billing)
Subclass 'zcl_cor_email_handler' and re-define the 'handle_request' method
Similarly implement all other classes for sms, fax etc.
CoR Chain master control table
Create a table with appropriate data elements and maintain entries as shown below
Triggering program
Create a test triggering program as shown below
Output
Extending the application
Testing requirement - New class and its functionality only as none of other code re-compiles
Testing requirement - Required only for newly created class and its logic and it's factory
Pros and Cons of CoR Pattern
Pros
Cons
Hope you find the example useful and able to apply the pattern to your OO design needs. Share your experiences wherever you applied CoR pattern / variations of the same in your code. Ciao !
Let me ask you, what do you think about the flow diagram below ?
Left most image is often called "spaghetti wiring mess" , second one is an "organized and labelled wiring" and last two are the SAP icons for 'Code' and 'Coffee' respectively. Obviously I am at the last stage in this flow ! So let me explain a little bit about 'Code' while having this 'Coffee'.
Developing software is fun for coding enthusiasts. It is indeed a lot of fun for experimentation, however when customers pay you for the software you create and maintain, it is a lot of responsibility on the designers and developers to deploy solution without causing maintenance nightmares. This is when the design patterns becomes very handy !
Design Patterns
Design patterns are primarily techniques envisaged by much experienced developers in order to solve common design problems in most efficient way by improving re-usability, maintainability, readability and extensibility of the software. There are many design patterns most developers are familiar with to name a few are - MVC , Factory, Singleton, Observer , Decorator etc. Today I will talk about Chain of Responsibility (CoR) pattern with a use case. Before we start, let me briefly touch upon the widely acclaimed principles in the OO design known as - S.O.L.I.D principles introduced by Robert C Martin (Uncle Bob) .
SOLID Principles
Each letter in 'SOLID' represent one principle as explained below -
- Single Responsibility Principle
- A class can undergo changes only due to changes in one part of the specifications; meaning classes shall have unique reason to change
- Open-Closed Principle
- A class shall be open for extension but closed for modification
- Liskov substitution principle
- An object shall be replaceable with instances of its own sub types
- Interface segregation principle
- Many smaller interfaces segregated by their tasks are preferable than one complex interface ; Rely more on composition rather than inheritance
- Dependency inversion principle
- A piece of code shall not get re-compiled due to changes in lower level components; Rely more on abstractions rather than concrete implementation.
With these principles in mind, let's look at the pattern and the code
CoR Pattern Basics
In CoR pattern a request from caller is propagated through a chain of handlers in which the relevant handlers perform a task in response and calls next handlers until chain is ended.
All request handler classes are derived from a common interface each implementations shall have the handler methods with unique business logic to perform an action.
The reference to next handler instance in the chain is stored in a private variable within each object
CoR pattern is most applicable in the following cases -
- A sequence of actions need to be executed upon an event
- Number of handlers and the order need to be determined at run time
- Handlers business logic is not related to each other
- Loose coupling between caller and handlers is desired
Use Case
Let's say there is a requirement to trigger communication via various channels (email, sms, fax etc.) to business partners . Which channels are needed to be determined at runtime. Adding a new communication channel need to be plug-and-play with optimal testing required and no re-testing for other existing channels. It should be flexible to switch on/off a particular channel communication globally. Adding a new template of message (say new email message format) need to be quick and to be carried out with minimum testing required.
There are different ways to trigger messages, customize message templates etc. in ECC and S/4 by standard. But lets look at it from a custom abap development perspective this time.
How to fit this requirement to CoR pattern?
The crux of the design is an interface say request handler interface as explained above and all the handlers need to implement this interface. We can use factory pattern to instantiate each handler and all the handler classes need to be chained by adding reference to subsequent handlers in the private attribute.
Code Snippets
CoR Request handler interface
INTERFACE zif_cor_request_handler
PUBLIC .
* Reference to next handler in chain
DATA o_next_obj TYPE REF TO zif_cor_request_handler .
* Factory method for instantiating chain handler
CLASS-METHODS get_chain_instance
IMPORTING
VALUE(is_variant) TYPE char10 OPTIONAL
EXPORTING
VALUE(er_object) TYPE REF TO zif_cor_request_handler .
* Method to execute handler logic
METHODS handle_request
IMPORTING
!i_header TYPE zscor_header
!i_items TYPE ztcor_items
!i_control TYPE zscor_control .
METHODS set_next
IMPORTING
!er_next_object TYPE REF TO zif_cor_request_handler .
ENDINTERFACE.CoR Email handler factory
CLASS zcl_cor_email_handler DEFINITION
PUBLIC
CREATE PUBLIC .
PUBLIC SECTION.
INTERFACES zif_cor_request_handler .
PROTECTED SECTION.
PRIVATE SECTION.
ALIASES o_next_obj
FOR zif_cor_request_handler~o_next_obj .
ENDCLASS.
CLASS ZCL_COR_EMAIL_HANDLER IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Static Public Method ZCL_COR_EMAIL_HANDLER=>ZIF_COR_REQUEST_HANDLER~GET_CHAIN_INSTANCE
* +-------------------------------------------------------------------------------------------------+
* | [--->] IS_VARIANT TYPE CHAR10(optional)
* | [<---] ER_OBJECT TYPE REF TO ZIF_COR_REQUEST_HANDLER
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD zif_cor_request_handler~get_chain_instance.
CASE is_variant.
WHEN 'BILL'.
er_object = NEW zcl_cor_email_handler_billing( ).
WHEN 'DUNN'.
er_object = NEW zcl_cor_email_handler_dunning( ).
WHEN 'INFO'.
er_object = NEW zcl_cor_email_handler_info( ).
WHEN OTHERS.
er_object = NEW zcl_cor_email_handler( ).
ENDCASE.
ENDMETHOD.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_COR_EMAIL_HANDLER->ZIF_COR_REQUEST_HANDLER~HANDLE_REQUEST
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_HEADER TYPE ZSCOR_HEADER
* | [--->] I_ITEMS TYPE ZTCOR_ITEMS
* | [--->] I_CONTROL TYPE ZSCOR_CONTROL
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD zif_cor_request_handler~handle_request.
WRITE:/'-> Executing email handler'.
* <Implement handler logic here>
IF o_next_obj IS BOUND.
WRITE:/'........Calling next handler in chain.....'.
CALL METHOD me->o_next_obj->handle_request
EXPORTING
i_header = i_header
i_items = i_items
i_control = i_control.
ENDIF.
ENDMETHOD.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_COR_EMAIL_HANDLER->ZIF_COR_REQUEST_HANDLER~SET_NEXT
* +-------------------------------------------------------------------------------------------------+
* | [--->] ER_NEXT_OBJECT TYPE REF TO ZIF_COR_REQUEST_HANDLER
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD zif_cor_request_handler~set_next.
me->o_next_obj = er_next_object.
ENDMETHOD.
ENDCLASS.CoR Email handler (Billing)
Subclass 'zcl_cor_email_handler' and re-define the 'handle_request' method
class ZCL_COR_EMAIL_HANDLER_BILLING definition
public
inheriting from ZCL_COR_EMAIL_HANDLER
create public .
public section.
methods ZIF_COR_REQUEST_HANDLER~HANDLE_REQUEST
redefinition .
protected section.
private section.
aliases O_NEXT_OBJ
for ZIF_COR_REQUEST_HANDLER~O_NEXT_OBJ .
ENDCLASS.
CLASS ZCL_COR_EMAIL_HANDLER_BILLING IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_COR_EMAIL_HANDLER_BILLING->ZIF_COR_REQUEST_HANDLER~HANDLE_REQUEST
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_HEADER TYPE ZSCOR_HEADER
* | [--->] I_ITEMS TYPE ZTCOR_ITEMS
* | [--->] I_CONTROL TYPE ZSCOR_CONTROL
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD zif_cor_request_handler~handle_request.
WRITE:/'-> Executing email handler (Billing)'.
* <Implement handler logic here>
IF me->o_next_obj IS BOUND.
WRITE:/'........Calling next handler in chain.....'.
CALL METHOD o_next_obj->handle_request
EXPORTING
i_header = i_header
i_items = i_items
i_control = i_control.
ENDIF.
ENDMETHOD.
ENDCLASS.Similarly implement all other classes for sms, fax etc.
CoR Chain master control table
Create a table with appropriate data elements and maintain entries as shown below
Triggering program
Create a test triggering program as shown below
REPORT ztrigger_cor_request.
* CoR Chain related control table
DATA lt_controls TYPE STANDARD TABLE OF ztcor_controller.
DATA wa_control TYPE ztcor_controller.
* Holds CoR Objects to build chain
DATA o_corobj TYPE REF TO zif_cor_request_handler.
DATA o_cormain TYPE REF TO zif_cor_request_handler.
DATA o_nextobj TYPE REF TO zif_cor_request_handler.
DATA lv_variant TYPE char10 VALUE 'BILL'.
* Header, item and control parameters for handlers to implement logic
DATA wa_header TYPE zscor_header.
DATA lt_items TYPE ztcor_items.
DATA wa_contr TYPE zscor_control.
SELECT * FROM ztcor_controller INTO TABLE lt_controls WHERE active = 'X'.
LOOP AT lt_controls INTO wa_control.
IF o_corobj IS NOT BOUND.
CALL METHOD (wa_control-handler_class)=>zif_cor_request_handler~get_chain_instance
EXPORTING
is_variant = lv_variant
IMPORTING
er_object = o_corobj.
o_cormain = o_corobj.
ELSE.
CALL METHOD (wa_control-handler_class)=>zif_cor_request_handler~get_chain_instance
EXPORTING
is_variant = lv_variant
IMPORTING
er_object = o_nextobj.
CALL METHOD o_corobj->set_next EXPORTING er_next_object = o_nextobj.
o_corobj = o_nextobj.
ENDIF.
ENDLOOP.
WRITE:/ 'Entering handler chain..'.
CALL METHOD o_cormain->handle_request
EXPORTING i_header = wa_header i_items = lt_items i_control = wa_contr .
WRITE:/ '.. Handler chain Finished'.Output
Trigger COR request - Testing
Entering handler chain..
-> Executing email handler (Billing)
........Calling next handler in chain.....
-> Executing fax handler
........Calling next handler in chain.....
-> Executing sms handler
.. Handler chain FinishedExtending the application
- Let's assume in future , we need to add a new communication channel say - social media . We can achieve this by
- Create a new social media handler class referring to the request handler interface and implement the corresponding business logic in 'handle_request' method
- Add the channel configuration to the control table
Testing requirement - New class and its functionality only as none of other code re-compiles
- Let's say we need to add a new email message template for 'Escalation messages'. We can achieve this by -
- Subclass the email handler class and re-define the 'handle_request' method alone.
- Add the logic to create new handler class when criteria met.
Testing requirement - Required only for newly created class and its logic and it's factory
Pros and Cons of CoR Pattern
Pros
- Flexible to add, remove and extend the handlers in the chain
- A runtime determination of handlers and sequencing is possible
Cons
- The caller have to wait until all the handlers in the chain has finished execution
- Every handler need to implement all the interface methods at least in main handler class
Hope you find the example useful and able to apply the pattern to your OO design needs. Share your experiences wherever you applied CoR pattern / variations of the same in your code. Ciao !
- SAP Managed Tags:
7 Comments
