Deadly Designs?
Part Three-Bugging Builders
Let us be Gordon Ramsey for a day. We are running a Michelin star restaurant tonight. We advertise ourselves as the best Indian restaurant and claim to serve every Indian dish from thepla to thekua. On top of that, we boast of being very fast with our orders.
How do we deliver these tall promises?
We have all the dishes grouped into thaali. Each customer can choose a type from the ones we have available with us. This system not only increases our efficiency but also gives the customers a wide range of choices.
Let us break down each thaali into three components. Roti, Sabzi and a Dessert. Every time we get an order.
- The head chef instructs the cuisine specialist.
- The specialist gets and plates the prepared dishes.
- The waiter delivers the thaali to you.
As of now, we have two specialists. Thus, while putting it into code we will need about 5 supporting classes. We are breaking down each living entity to a class.
Here is a UML to show the system we use.
The Thaali Class:
- Represents the customer’s selection of dishes.
- Has methods to set customer preferences.
The Chef Class represents our head chef:
- Has an instance of the Thaali to set preferences.
- Has abstract methods that serve as orders to specialists.
The Waiter Class:
- Has methods to get orders.
- Has methods to communicate with the chef.
The specialist classes inherit and implement the order of the chefs.
Now that we are clear with our assembly line. Here is a small code sample to illustrate the same.
When do we need the Builder pattern?
- The main objects do not depend on the components.
We need a myriad of fresh ingredients daily. In supplier cuts, one of our ingredients does not mean we cannot serve a certain type of thaali. Also, we can continue to run the restaurant even in the absence of any of our specialists. This method also makes it very easy for us to add dishes to our menu.
- We want to hide details from the customer.
We need to be unique to have people coming back to us.
- We want to create complex objects easily.
The poor chef cannot cook so many dishes. Not only will it be hard for him to decipher the perfect taste, but the poor chap will also have a hard time looking into so many orders. This process not only eases the work but also is the sole reason for our efficiency.
However, this design pattern is not a solution to all our problems and has its fair share of drawbacks.
Disadvantages of Builder Pattern:
Can make the code unnecessarily complex.
Let us imagine that we bring on board more cuisines(Let us assume,20). We also decide to serve more than just curry and roti, bringing more base items. Any base item, Ex: A daal can be cooked in multiple ways depending on the cuisine. All these myriad of tweaks can give any dev guy/girl sleepless nights.
The pattern fails terribly as the complexity of the software increases. It becomes harder and harder to scale and maintain the pieces of code written.
All these problems bring to picture another design pattern. The “Decorator”, which I will be covering in the next issue.
Till then. Stay safe :D