[TECH] GUHADA and Java Design
Another GUHADA update is here!
Check out further development progress of GUHADA about “Chain of Responsibility Java Design Pattern”.
Please take your time reading through, since this may be an important aspect of GUHADA that you might want to know.
So from now on, you may find out the updates on the GUHADA project once in 2 weeks between our other contents, since the development progress could be useful information for everyone. Our development team supports creating contents about the technical development process, so the contents will show almost exactly how GUHADA is being developed.
Java Design Pattern Chain of Responsibility
Chain of Responsibility pattern is known in diverse names:
- Transfer of Responsibility
- Continuous Responsibility
- Action Chain
- etc..
The usage
So when is the chain of responsibility pattern used?
It is used when requests are received and pass along through the chain of handlers. If there are signal requests for the emails, the chain of responsibility pattern separates the requests to the applicable receivers based on the signal received. In the case of the program writer, it is used to check the mutation of data at the point during the operation of the application to check the MDM installation status. When a signal (SMS, Email, Push) request is made, it is used to validate the signal where the receiver can handle the signal. Also, when the member registration request signal comes in, it is used to make the validation.
Advantages
It can delete the space in between the objects, separating their roles clearly. By changing the order of each object, the entire characteristics of the chain can be altered.
Disadvantages
The debugging is difficult.
The objects that are attached to the chain, you have to check each of them one by one to find out their actions. It is not easy to determine how far and where the tasks have been processed. The writer has to create an exception in order to determine which object on the chain has caught on which step.
Examples
Receiving the request from the Push Message, we’ve made a chain to validate whether the sender can signal the Push Message.
The highest object that creates the chain is AbstractValidation.
Client (main) for the creation of the chain:
Thank you for supporting TEMCO.
We’ll be back with more updates and exciting news.
TEMCO: Innovative Supply Chain Data and E-Commerce Solution through Blockchain and Smart Contract Technology.
▶TEMCO Chatroom: https://t.me/temcolabs
▶TEMCO Official Website: https://temco.io
