Design Patterns: Part 2
In this article, we will explore the Builder Design Pattern and the Chain of Responsibility Design Pattern. The Builder comes under the Creational Pattern, and the Chain of Responsibility comes under the Behavioural Pattern. Let’s explore more on these patterns individually.
Builder Design Pattern
The Builder Pattern uses the step-by-step approach in building complex objects using basic simple objects. This pattern comes under the Creational Pattern as it provides one of the best ways to create an object. The builder is independent of other basic simple objects. The builder pattern helps to separate the construction complexity of an object. Therefore, we can use the same process to create different implementations. The construction process should be generic so that it can be used in different ways. Usually, the builder returns an instance of itself while doing the construction processes. Thereby, different constructions can be chained together, and it will finally return an object that has been build using the builder. Apart from that, the builder pattern also helps to avoid the Telescoping Constructor. Usage of the telescoping constructors will make your code structure complex.
Usecase of Builder Design Pattern
For this scenario, we have used a query building use case in databases. We have a class called Query, which contains private attributes as SELECT, FROM, and WHERE. The QueryBuilder class has a property to hold a Query object, and it will create a Query object inside of its constructor. QueryBuilder will have methods to set SELECT, FROM, and WHERE to the Query object, and each method will return a QueryBuilder object for the chaining process. Finally, it will implement a method called build() to returns the Query object. If both SELECT and FROM properties are not set query building process will return an error message.
Chain of Responsibility Design Pattern
The Chain of Responsibility will create a chain of handlers (receivers) for a request initiate by a client and handle them in some sequential order subjected to constraints. This pattern decouples the sender and receiver of a request based on the type of request. The Chain of Responsibility comes under Behavioral Patterns. In this pattern, handler objects of the request contain references to other handler objects. Therefore if one handler can not process the request, it will pass that request to the next handler in the chaining process. Logger in Java API is a real-world example for the Chain of Responsibility Design Pattern implementation. We can use this design Pattern when;
- To decouple the requests of sender and receiver.
- When multiple objects are competing to handle requests in a runtime.
- When you issue requests to one of several objects without specifying the exact receiver.
Usecase of Chain of Responsibility Design Pattern
In this scenario, we have considered the use case of patient-doctor interaction in case of illnesses. We have a class called Patient, and it will have the attributes like the name, age, and disease severity. Disease severity is divided into four categories as LOW, MODERATE, HIGH, and CRITICAL. For patient handling, we have an abstract class called Handler. As subclasses of Handler, we will have different types of doctor classes like TraineeDoctor, GeneralDoctor, SeniorDoctor, and Consultant, which handles patients depending on the disease severity. Trainee Doctors will handle patients with LOW disease severity, General Doctors will handle patients with MODERATE disease severity, Senior Doctors will handle patients with HIGH disease severity, and CONSULTANT will handle patients which are in CRITICAL conditions.
Each Handler subclass will keep a reference to each other in the order of their hierarchy. The order of the doctor hierarchy is as follows.
TraineeDoctor —> GeneralDoctor — > SeniorDoctor — > Consultant
For further more clarification check these resources;