We listen various technologies names, algorithms names, design pattern names etc, in our
daily work life. Many use these terms to convey their message in lesser words & funny thing,
is that many use these terms just to show that they have sufficient knowledge.
Adapter Design Pattern is one that name which one sees multiple times in various contexts.
So, one can see the details of this over the internet as there are hundreds of articles about this.
My purpose, is to convey what & how I see it.
If we focus on the word 'Adapter',then we get the idea that it is something which is adapting
to our requirements, something which is working as some controlling bridge between the
source & its consumer. Like what?
In Real Life :
a) We have used Voltage stabilizers, to control the voltage being supplied to our valuable
appliances. So it adapts its working to lower or increase the voltage.
b) We have used 2-3 pins adapter to plugin various kind of pins to power-up our appliances.
c) We all have adapters in the power cord for our laptops.
d) We all have used Inverters for power back-up, which converts AC to DC or DC to AC.
In Code :
a) We can create our adapter class either by providing public overloaded methods, such that
those methods will be taking the type of various kind of Input which you support.
b) We can provide only one public method which will taking Input of any type, then based on
the supporting, it will call any one of the above methods, which are now private.
In (a), user must be aware about the kind of data for which one method can be called,
in (b), user needs not to be aware about the kind of data, but must handle the output/exception
if that input type is not supported.
c) We can have an Interface for an adapter & then can provide various implementations for
our requirements.
d) We have a concept in Microservices, where we can spin-up new instances over the cloud
if load increases & extra instances are removed if load decreases. So I see it as an
adapter.
So I see, we use Adapter pattern in various forms in our daily life & in code, it just depends
how we look at that problem & its solution. And again one must focus on the better solution,
rather focusing on the kind of design pattern to follow & design patterns are irrelevant during
the start of the product development.
Once your development reaches to some stable stage then look back & see what design
pattern has been followed & the name of that pattern, may be, you can use during your
presentations & documentation but don't put any constraint on the product evolution by
forcing any design pattern.
daily work life. Many use these terms to convey their message in lesser words & funny thing,
is that many use these terms just to show that they have sufficient knowledge.
Adapter Design Pattern is one that name which one sees multiple times in various contexts.
So, one can see the details of this over the internet as there are hundreds of articles about this.
My purpose, is to convey what & how I see it.
If we focus on the word 'Adapter',then we get the idea that it is something which is adapting
to our requirements, something which is working as some controlling bridge between the
source & its consumer. Like what?
In Real Life :
a) We have used Voltage stabilizers, to control the voltage being supplied to our valuable
appliances. So it adapts its working to lower or increase the voltage.
b) We have used 2-3 pins adapter to plugin various kind of pins to power-up our appliances.
c) We all have adapters in the power cord for our laptops.
d) We all have used Inverters for power back-up, which converts AC to DC or DC to AC.
In Code :
a) We can create our adapter class either by providing public overloaded methods, such that
those methods will be taking the type of various kind of Input which you support.
b) We can provide only one public method which will taking Input of any type, then based on
the supporting, it will call any one of the above methods, which are now private.
In (a), user must be aware about the kind of data for which one method can be called,
in (b), user needs not to be aware about the kind of data, but must handle the output/exception
if that input type is not supported.
c) We can have an Interface for an adapter & then can provide various implementations for
our requirements.
d) We have a concept in Microservices, where we can spin-up new instances over the cloud
if load increases & extra instances are removed if load decreases. So I see it as an
adapter.
So I see, we use Adapter pattern in various forms in our daily life & in code, it just depends
how we look at that problem & its solution. And again one must focus on the better solution,
rather focusing on the kind of design pattern to follow & design patterns are irrelevant during
the start of the product development.
Once your development reaches to some stable stage then look back & see what design
pattern has been followed & the name of that pattern, may be, you can use during your
presentations & documentation but don't put any constraint on the product evolution by
forcing any design pattern.