Design Pattern — Structural — Low level system design — Decorator, Proxy, Flyweight design pattern (part 3)
Structural Design Pattern helps us to understand how to create a complex objects from a simple initial base object while making sure that object is greatly efficient.
In the previous blogs, I mentioned about creational Design Pattern which emphasizes on creation of classes in a reusable and efficient manner. if you have not gone through that then I would highly recommend you to give that a watch before going through this blog. Here’s a link for the same
Now, Let’s dive into Decorator design pattern
Decorator Design Pattern:
Decorator design pattern talks about how to create and provide multiple enhanced options for a base class in future while creating a simple base class at the time of initial setup.
Example: Let’s say we are designing a simple subscription system where we offer multiple plans such as Enterprise and classic. The initial setup would look like this
Next, we let’s say we wanna provide set of add on options as well for every single plan, then we can create a new abstract class extending the subscription abstract class like a decorator wrapper on top of main class.
So now our main service class would like below
Proxy Design Pattern:
Proxy design pattern comes into picture when you wanna add a firewall on top of your service class.
Example:
One such classic use case of proxy design patterns in the industry is across helpers and service classes. Let’s say we have a service class and we need to add a helper on top of our service class to format the incoming body object then aligning our code in like below format will help us to achieve the same.
This can be applied to a lot of concepts. one such classical example is when we have a router and wanna assign a certain level of strategies on top of the router to provide auth for an incoming request.
Flyweight Design Pattern:
This design pattern helps in reducing the object count when we huge number of objects.
The cache is a classic example of a flyweight design pattern where the data is stored temporarily in a cache based on its requirement.
The below code demonstrates the same.
Let’s say we have a simple subscription object associated and this subscription object are been instantiated with various types
Now if sub2 and sub4 are mostly accessed objects then we create a cache layer around this which could be further stored in memory for faster access. The below code explains the same
