Design Patterns-YouTube Transcription
Design Patterns-YouTube Transcription
hello friends welcome to architect interview question series by knowledge powerhouse and in this
series we are covering questions on system design software architecture design patterns and
these are like very good concepts to learn even for your day-to-day life where you are working in
your office and you want to apply these principles or concepts let's go on to our next question
question is what are the different types of design patterns in oops so in object-oriented
programming we have some design patterns and these design patterns are very defined ways to
solve some things for problems and design patterns occurring like not only object-oriented
programming but also in different programming streams but now in this question we are focusing
more on the design patterns of object-oriented programming on so in object-oriented
programming we have mainly three categories of design patterns fastest creation on these are the
patterns which are used for creating different kind of objects classes or entities then we have
structural design patterns this category of patterns are used to build the overall architecture in
your architecture you have different kind of structure like if you see a physical architecture you
have kind of a bridge right whenever you have like two different roads that you want to connect or
you have like some kind of a facade so similarly in object-oriented also use structural design
patterns and third category is behavioral one which is like peers in the behavior the state of the
software how it can work in different kind of conditions so those are the behavioral design
patterns let's go into detail of each of these categories and learn about some of these patterns in
detail so in creational design patterns some of the popular design patterns are builder factory
method abstract Factory object to singleton and prototype so these are like seven means six seven
main methods design patterns let's go on to each of them sin builder design pattern we have like
you know some kind of a flexible solution that can provide I was making a problem of creating an
object if you want to create an object then you can use builder design pattern and the intent here
is to separate the construction of a complex object from it's a representation like I mean you
actually are getting an object and you can start working on it but before you get it you have to
build it let's say I mean you get a cup of coffee so to get that cup of coffee there is a complexity
model building it like you need to add sugar you need to add cream you need to add which type of
cream to be added what temperature it has to be like you know go into and what kind of coffee
you what kind of bluing is required so all the things are taken in the case of building that coffee
and later on you can be your certified so build your design pattern solve certain problems first
problem it can solve is then how can the class create different representations of a complex object
like how can you create different kinds of coffee I mean if you have to create latte with like milk or
cappuccino with like so ml I with coconut milk so all these kind of a different objects can be built
using visual pattern and then the user can start using it right another problem that Builder design
pattern salsas how can a class include creation of a complex object in a simple way I mean if you
want to create the object in a simple way how we can like you know provide that to calling class
like if a client can see like if you see in this example there is a director and then in the Builder we
have a generic method called Bill part right and in the Builder you have a country little so that
concrete builder is the one where they actually implement the build part and there can be
multiple bit parts right like they say in case of coffee you are like adding milk adding sugar adding
like so you can keep on adding all those things right then finally when you call the get results then
you will get the actual product and that product is returned back to the dirt so that way the
Builder design pattern works another popular design pattern in the traditional one is factory
method in factory method we try to solve the problem of creating objects without specifying the
class of that object because like clients they may not know like what class they are going to get so
they can just be given an interface that this is the kind of object you are you're getting but the
actual product will be different which is dependent on the factory that we are using at that time so
this is done by creating objects by calling it factory method and this is especially specified in an
interface and like it can be implemented in a base class and it can be overridden by derived classes
like in this example the Creator has a like interface product now the actual creator one will call the
factory method right and factory method will instantiate the actual product which is product one
that will be created based on the conditions of the factory and then that product is returned to the
Creator so creator doesn't know the real product till the time of creation all all it knows that it
expects some product of type product right like product one is software like instance there is a
regular is a subtype of product right so that way the concrete product is given at the end but
initially all you need know is the interface of that another design pattern is singleton design
pattern and this is more like an Tibetan also in this singleton we restrict the instantiation of a class
to one single instance so in the whole system you will only have single instance of this class it is
very useful when we need one object to coordinate across different systems like you know overall
system needs one object to coordinate then we created singleton and singleton will solve certain
problems like that how we can ensure that class is only one stands and how we can ensure that
only one instance in excess easily and how we can control the instantiation of the class like we
don't want others to create is multiple instances of this class and that can be restricted by
singleton design factor and one more design pattern we want to cover in this is prototype design
pattern this is also creational design pattern here like we use it to create the objects and they are
determined by prototypical instance now this is like you know clients they have to clone to
produce new objects this proto the pattern is used for avoiding subclasses of an object creator in
the client application like factory method does so it avoids the inherent cost of creating new
objects it can just create a new object by using clone so you don't need to do new rotate an object
you just have a prototype right which is like original now what you do is that you do prototype
clone and that will create a like another instance for you so based on that if you have to do new it
might be very expensive to create that object whereas using a clone is much cheaper and lesser
intake you know intensive on your resources and it will solve the problems like how can we create
an object so that the objects can be specified at runtime that you know we can just say that this is
the more objects you want to create use clone and it will create a copies of that and how we can
dynamically load these classes in their system like that also is the problem that is sort of like so if
you see this UML diagram here the client class is requesting for the product and that product is
like you know not insatiate by product one right so instead the client will refer to prototype and
the prototype interface is having a method to flow now prototype is like you know subclass I mean
implemented by country prototype one will come to a prototype - so we have two copies out of
writing at the tomb like different kinds of prototypes in our system which are the concrete
prototypes now the client class needs a copy of that so what they do is that they just call clone to
create it so once they get the clone then they will get that object and that will be the one they can
start using because it's a copy of the original object the next category of design patterns is
structural design patterns here we have popular design patterns like adapter Bridge facade
decorator composite fly weight and proxy so if you see the diagram this is the structure is being
used to create the structure like not to create one object but to create the structure like if you
here we are creating in kind of an pyramid so we can use a specific form in which this pyramid can
be created by actual objects so objects are already created by using traditional pattern now here
we are creating the different elements of the structure so let's understand a doctor design pattern
in this adapter design pattern we have a alternating like you know we also call it as a wrapper
design pattern and what did this pattern does is that it allows us to like user interface of an
existing class and adapt it to the intake you work with another class so that we can like you know
two classes can work with each other mainly it is used to make existing classes work with other
classes without modifying your source code so I mean if you see an example where you have
document object model Dom of an XML document and then you can use it to convert it into
different kind of interfaces as a class so that people can work with the Dom model so a doctor
model solves problems like how can a class PG use that does not have an interface that eggplant
client requires like I mean client requires a specific class or specific interface but your original class
doesn't have it now you can create an adapter class that will convert like you know that will
translate the class into the kind of an interface then the client requires if you see this example you
have a like trine and then you client is calling to a target interface and that target interface goes
through like adapter and then a doctor is providing the interface to client I and an adapter is and
into the adapter which is like your own class then your whole class it doesn't match what client
requires right it has the capability but the interface doesn't mind so using an adapter you can
convert that interface according to the client now in future if anything changes to the interface
then you only need to change them specific interface will not your original class that is the help we
get from adapted design pattern so you know written class can remain same only the adapter
needs to keep changing another design pattern is bridge design pattern and it's also like using
some friends using to decouple an abstraction from the implementation it looks similar to that
opera but it's a little bit like if there is minor differences between this so here like we use
encapsulation aggregation and even inheritance to separate the responsibilities into different
classes so the problems that bridge design patterns all are that we have an abstraction in its
implementation and both of these things should be defined and extended independently from
each other like from from an abstraction in this diagram we extended to another abstraction and
then from implementer like we have another implementation so that way the abstraction and
implementation can be inherited so if you see in this diagram the abstraction isn't implemented as
usual in single inheritance hierarchy there is one area for an abstraction and the other is for
implementer that way we can use it then we have facade design pattern again facade is also
similar to a doctrine here like client wants to access over multiple classes instead of one class in a
doctor nominees for one class in this case the client wants to access methods in multiple classes
now what we do is that we create a facade using that facade reacts we expose the methods of the
underlying process right so that we find is a need to deal with our internal classes of internal
subsystem they just need to with one facade class and that is the one will give them interface to
multiple classes right so facade can improve the readability and usability of our software library
and it can last the interaction with more complex components behind single API so it can we can
just create a single API and that is the one we can give it to the point where is that API behind the
senior served by multiple classes so facade solves a problem like to make a complex system easier
to use and provide a simpler interface and it also solves the problem of dependencies like that the
client has in the subsystem not the client has dependent only on the facade right it doesn't have
dependency on all the other classes of that subsystem so these are the problems that society sine
petals also so a doctor design pattern we already covered and then we have composite design
pattern in composite design pattern we try to describe a group of objects that have to be treated
the same way as a single instance of the same type of object so the intent here is to like compose
objects into tree structure so that they can represent the part or whole variety like I mean in this
case if you have a leaf I mean component and then you have a leaf right and then leave or it can
be a composite again so you can have if you see like a component under the comprehend or under
the component kind of a thing so like I mean basically the component can end in a leaf or it can
end into a sub component and everything so that way collection of that conformant overall
composite object like I mean if you have proper example in an organization you have like a CEO
and under Cu Cu is the manager and then under C and employers under Cu we have more people
who are liking next level VP easy in every piece they also are managers as well as they are
employees so that way using that we can have the whole system can be created by the parts as
well as late by the whole composite also so that forms like a basis of composite design pattern
now next set or design patterns are behavioral design patterns in behavioral we have command
iterator chain of responsibility observer state strategy mediator interpreter all these design
patterns so in command design pattern what we do is that we encapsulate all the information
needed to perform an action or trigger an event at a later time so this information includes a
method name and the object that owns the method and where these were the method
parameters for example like I mean if you have a every mode right in the remote we can use a
command design pattern they can remotely just have some buttons right but each button is a
different command right and those commands are actually methods that are like things like
increasing the brightness of your TV increasing the volume of your TV right so all those are
different different methods that are involved by causing those buttons and then when you have
those buttons then you can even combine those commands to form a complex EM iron or you can
have an undo kind of a thing you can go back I mean all those things can be done so as long as we
have commands mapped to some kind of methods you can make use of this so with command
design pattern we solve problems like coupling the invoker of a request to a particular request I
mean that coupling is avoided and because it's not Hardware and then it's like if you remember in
old times or like there are devices where you have to go to the device and then press the button
which means like it's a hardwired thing whether it's in a remote like I mean you just press the
button anymore and it translates to the method which is within the device if you see this example
we have in vocal invoker is calling the command and that command is actually executing and
calling the action on the receiver so that's how it works invoker doesn't know about the action on
the receiver it knows about the command and command translates into the action another
behavioral design pattern which is very popular is an iterator in the iterator we can use it to travels
at container and access all the elements of a container like Emily if we have a collection like a
queue or if we have a like some kind of a tree so we can iterate through all the objects within that
container so there are like you know different kind of algorithms different kind of iterators so the
primary purpose is that iterator will D couple the algorithm from the container like container tree
knows how to like organize the data within it early but she doesn't know how to traverse it but if
you get a iterator knows that whether you want to go red for search in the tree or you want to
depth-first search in the tree so you can use those kind of iterators to traverse the tree the
problem solved by a traitor design pattern are like the elements of an aggregate object should be
exist and Traverse without exposing its representation so you don't need to know the
representation of tree you can just reverse it like if you have down parcel and then we have sex
Power Cells like then we can use that to just traverse it and then we have a strategy design pattern
this is also a behavioral design pattern in this design pattern we enable selecting an algorithm at
runtime so like administrative hardwiring the algorithm at runtime we can specify what strategy
should be used so the clients they can specify what is the context and based on that context the
specific algorithm will be picked up so in this class we have a context and then we have strategy
interface with some algorithm and then we have strategy one or strategy two so these are two
different strategies that that have two different algorithms now when the client calls the
algorithm then it comes to know that oh now is the time to call it strategy one so client calls the
same method algorithm but in reality behave the same because of the context the right kind of
strategy is big and that will be returned so one example is like if you have a shape kind of a class
and you are calling a method calculate area now if client wants to call the like you know this
method of shapes calculate the area then it has to specify what type of object is that if it says that
type is circle then the area will go to the concrete implementation of circles area which is PI R
square and if trying says the oktai P Square then it will just go to R square which is the side of his
car so that way the strategies define at the runtime based on the context all right that's all on this
topic of design patterns and it is very good to know these patterns in detail and we will have a
series on this and soon we will be getting it and if you want I have more question in this then put it
in the comments we'll be happy to answer that for you and keep that in your feedback come to us
that way we can improve these videos we can cover more topics that you are interested in thank
you and do like this video and share it with your friends so that they can also prepare well for
interview