Discover how simple recipes for object creation can save you hours of frustration and bugs!
Why When to use which creational pattern in LLD? - Purpose & Use Cases
Imagine building a complex app where you must create many objects manually, each with different setups. You write code everywhere to make these objects, changing details each time.
This manual way is slow and confusing. You repeat code, make mistakes, and struggle to change object creation later. It's like baking each cake from scratch without a recipe, wasting time and risking errors.
Creational patterns give you clear recipes for making objects. They organize creation steps, so you reuse code, avoid errors, and easily change how objects are made without breaking everything.
if(type == 'car') { return new Car(color, engine); } else if(type == 'bike') { return new Bike(color); }
VehicleFactory.create('car', {color, engine});It lets you build flexible, clean systems where object creation is easy to manage and adapt as your app grows.
Think of a coffee shop: instead of making each coffee by guessing ingredients every time, you use standard recipes (patterns) to quickly prepare any drink perfectly.
Manual object creation is repetitive and error-prone.
Creational patterns provide reusable, clear ways to build objects.
Choosing the right pattern makes your system flexible and easier to maintain.
Practice
Solution
Step 1: Understand the requirement for a single instance
The question asks for a pattern that ensures only one instance of a class exists.Step 2: Match the pattern to the requirement
Singleton pattern restricts instantiation to one object and provides a global access point.Final Answer:
Singleton pattern -> Option AQuick Check:
Single instance = Singleton [OK]
- Confusing Factory with Singleton
- Using Builder for single instance
- Thinking Prototype creates single instance
Solution
Step 1: Identify the pattern for flexible object creation
The question wants a pattern that creates objects without exposing the creation logic.Step 2: Match the pattern to the description
Factory pattern provides an interface to create objects but lets subclasses decide which class to instantiate.Final Answer:
Factory pattern -> Option BQuick Check:
Flexible object creation = Factory [OK]
- Choosing Singleton for flexible creation
- Confusing Builder with Factory
- Selecting Adapter which is not creational
class CarBuilder {
constructor() {
this.car = new Car();
}
setColor(color) {
this.car.color = color;
return this;
}
setWheels(wheels) {
this.car.wheels = wheels;
return this;
}
build() {
return this.car;
}
}
const car = new CarBuilder().setColor('red').setWheels(4).build();
console.log(car.color, car.wheels);What will be the output?
Solution
Step 1: Check if Car class is defined
The code usesnew Car()but Car class is not defined anywhere, causing a runtime error.Step 2: Understand the consequence of missing class
Since Car is undefined, the code throws a ReferenceError before any properties are set.Final Answer:
Error: Car is not defined -> Option DQuick Check:
Missing class definition = ReferenceError [OK]
- Assuming output is 'red 4' without Car class
- Ignoring missing class error
- Confusing Builder pattern with Factory output
class Logger {
constructor() {
if (Logger.instance) {
return Logger.instance;
}
this.logs = [];
Logger.instance = this;
}
log(message) {
this.logs.push(message);
}
}What is the main issue with this implementation?
Solution
Step 1: Analyze Singleton enforcement
The constructor returns existing instance if present, but the implementation does not fully prevent multiple instances.Step 2: Identify the issue in JavaScript context
In JavaScript, this pattern works but can be bypassed by other means; better to use static method to get instance.Final Answer:
It does not prevent multiple instances -> Option CQuick Check:
Singleton enforcement flaw = It does not prevent multiple instances [OK]
- Thinking logs are not stored
- Assuming new instance is always created
- Ignoring missing retrieval method
Solution
Step 1: Understand the complexity of the object
Meal orders have many optional parts and require step-by-step construction.Step 2: Match pattern to complex object creation
Builder pattern is designed to build complex objects step-by-step, allowing optional parts to be added flexibly.Final Answer:
Builder pattern, because it simplifies creating complex objects step-by-step -> Option AQuick Check:
Complex object with options = Builder [OK]
- Choosing Singleton for multiple orders
- Confusing Factory with Builder for complex objects
- Using Prototype without cloning need
Ready to prove it?
Pass the test and this pattern moves unknown
