Factory Design Pattern:

It’s an type of creational design pattern which are used for different object creation depending upon
the situation.
Builder Design Pattern:
Adapter Design Pattern:
_____________________

This is the part of structure design pattern.

Composite Design Pattern:
_____________________________

It’s part of structure design pattern.

When ever we have a scenario we want to create an object and which represents a tree structure.

ProtoType Design pattern:

____________________________

It’s also a creational design pattern.

If we want to create object then factory is the best way but if there are certain scenario where we
want to create an object and object creation takes lot’s of memory or may be it takes lot’s of time for
creation.
Let’s say if we want to create an object that is created with the help of database i.e. it’s created with
some initial value which is coming from database so it’s take time.

So if we go for second object then why we are creating the second object that get value from
database instead of this we can fetch first object data into second object.
Something like copying the object or cloning the object. Clone Concept.
Observer Design Pattern:
-------------------------------------------

Explain in project:
________________________________________________________________

Ultimate LLD and HLD Roadmap | System

Design RoadMap | LLD & HLD Topics to
be covered for Interview
The above logic do not follow the single reason to change because here there are three reason to
change invoice class.

Solution :make different class to which change only for one reason
Solution:
Problem in our code when we are passing the object of motarCycle as :
Bike b=new MotarCycle(); we have feature to b.turnonEngine();
But suppose now we do :

Bike b=new BiCycle(); now if we do b.turnonEngine(); =>it give exception which is issue.

i.e. here Bicycle is narrow Down the functionality of the Bike class which is Contradictory to Liskov
Substitution principle.

Issue is that here waiter need to implement each method of RestaurantEmployee which is
unnecessary to him ,his job is only to implement’s serveCustomers().
Solution : here we need to segregate the interface :

Here issue is that MacBook is depends upon Concereter class rather than interface so in future we
can not change wiredKeyboard with Blooth keyboard since it depend upon the concrete class .
solution:
Now we can switch wired and Blooth both depends upon the use case.
Problem Section:
Solutions :put very common generaic function which is common for all in the interface.

Now if I add the MotorCycle engine if I try to call hasEngine() method it’s not allow because Vehicle is
not aware about hasEnginer() for this we have to use EngineVehicle .

Also we are not allowed to Bicycle in EngineVehicle ,so all problem get sorted.
Issue’s with current Design: in this design as we can see sports vehicle and offroad Vehicle in drive
function both are implemented specialCapability. Which is same code and it’s repeated i.e. not dry
concept.
In future if there are more class having same drive function then all will write same code which is not
good. It conflict the DRY concept.

Root Cause of the issue : this is arise when

Suppose For parent p have 5 child c1,c2,c3,c4 and c5. But implementation of c1 ,c2 be same and
c3,c4 have same implementation

i.e.
children of any parent for any function there implementation is same then this cause arise i.e. it’s not
follow Dry concept.(Do Not Repeat Yourself).

Solution For This problems: we use strategic design pattern.

Example:
Design Pattern By Ridhi Datta:::::
________________________________________________________________
Bilder Pattern:
Now If we required to add more attributes then we need to pass that thing in contructor as well
now strive code failing because he has pass the argument only for previous attributes but here more
filed are added so this problem is know as Backword compatibility fail.

One solution is overload the constructor with required field but if we have different user then
according to there situation we always have to overload the constructor which cause problem so
it’s not good it’s really really bad and also client need to remember the ordrer of the parameter in
the constructor.
Solution :

If we make a func function in x which give instance of dog to we can do following way.
Now there is a one scenario suppose if we delete the dog class then there is no need of x class
so can we do better by inserting the x class into dog clas.
one more things is any new client come and he want’s to add more more attributes so we have to
changes both class that is dog and x both and there may be change that developer might we forget
to do changes in both files.
But after add the x class into dog class
our implementation change:

But here as it’s clear to create dog class we need x class but x class we now access without creating
the dog class since it’s inside the dog class which cause the conflict.

To solve this problem we need to create x class as static. Because static member can access using
class name as well.
So now it’s became:

For name convention we can call x as DogBuilder and func as build.

++++++++++++++++++++++++++++++++++++++

Decorator Design Pattern:

+++++++++++++++++++++++++++++++:
:

Design Vending machine:

--------------------------------------------------
SingleTon design Pattern::::::::::::

But here we can not call the getTVSetInstance() without creating the of object ofTvSet.
so to solve this me make getTVSetInstance() static.
Now In the multithread environment :::
Output:

This is because both thread parrally work and they get TVInstance value as null so two object created

So to solve this problem :

But the problem with this design is that our entire function gets synchronized. For example, if we
have threads t1, t2, ..., t120, they all have to wait. However, we can make a change here. Threads
should only wait when the object is not created. If the object is already created (TVset != NULL), they
don't go in if block to create a new instance.
So we only need to synchronized object creation nothing else:
Builder Design Pattern:
-------------------------------------------
---------------------------------------------