clarification between design patterns
Moderator: General Moderators
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
clarification between design patterns
in structural patterns, there are
1. adapter pattern
2. facade pattern
both these patterns appear to be similar
1. as i understand from adapter pattern, we are developing a new interface for a client as the client is not happy with the interface provided by functionality providing class
2. facade is, when there is a huge set of classes and you develop a set of interfaces so that you can easily avail services provided by those classes.
Can anybody explain me when you would choose one of these patterns for a problem?
1. adapter pattern
2. facade pattern
both these patterns appear to be similar
1. as i understand from adapter pattern, we are developing a new interface for a client as the client is not happy with the interface provided by functionality providing class
2. facade is, when there is a huge set of classes and you develop a set of interfaces so that you can easily avail services provided by those classes.
Can anybody explain me when you would choose one of these patterns for a problem?
Adapter adapts one implementation to another, facade hides complexity behind a specific interface.
This is not a perfect example, but here it is. Imagine you have your own class for sending e-mails:
And you decide to switch to a third party library, which has the following interface:
Your code has $mailer = new Mailer(); and $mailer->send(...) all over the place. Now you turn your Mailer class into an adapter for OtherMailer. This step (refactoring your class) is no part of the adapter at all, but here it is, for the sake of this example:
This class is now an Adapter for the OtherMailer. The main goal here is to adapt a known (and used) class to another class with a different interface.
Now for the Facade pattern. Imagine a complex xml writer:
If you have to write a specific xml (say to write your User class to an xml), you don't want to clutter your code with assembling the complex xml, so you hide the logic behind a facade:
This class is a facade in terms that it uses the more complex library available to present an easy interface to a specific solution.
The examples are not the best, both can be improved, but they do their job, I hope.
Best regards
This is not a perfect example, but here it is. Imagine you have your own class for sending e-mails:
Code: Select all
class Mailer
{
function send($target, $subject, $body);
}Code: Select all
class OtherMailer
{
function setTarget($target);
function setSubject($subject);
function setBody($body);
function send();
}Code: Select all
class Mailer
{
function send($target, $subject, $body)
{
$mailer = new OtherMailer();
$mailer->setTarget($target);
$mailer->setSubject($subject);
$mailer->setSubject($body);
$mailer->send();
}
}Now for the Facade pattern. Imagine a complex xml writer:
Code: Select all
class ComplexXmlWriter
{
function open($doctype);
function writeElement($element);
function close();
}
class ComplexXmlElement
{
...
}Code: Select all
class User
{
var $name;
var $email;
}
class UserXmlWriter
{
function write($user)
{
$writer = new ComplexXmlWriter();
$writer->open('...');
$writer->writeElement(new ComplexXmlElement('name', $user->name));
$writer->writeElement(new ComplexXmlElement('email', $user->email));
$writer->close();
}
}The examples are not the best, both can be improved, but they do their job, I hope.
Best regards
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
That is correct. Thanks dbevfat.Jenk wrote:Those are good examples, dbevfat, well, they worked for me at least. Thanks
So basically, adapter just develops a new interface to the service-providing class so that existing code can still work without any modification
facade is used when you think directly communicating with service-providing class is complex and you do some pre-processing before you forward to service-providing class.
as you guys know understanding design patterns is difficult and it is mainly because there is not much freely available good documentation on design patterns. There is a website being partly run by our community member which talks about PHP design patterns. the website is good but not written in a way that could be easily understood, you guys can think of sharing your knowledge there. I still use wikipedia's material on design patterns as reference.
I believe the key difference between the two is the Adapter targets one class, while Facade targets an entire subsystem (with potentially many classes, factories and builders). The goal of both is to provide your code with a more palatable API than the original API of the code you are Adapting/Facading.
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
that is another good definition.sweatje wrote:I believe the key difference between the two is the Adapter targets one class, while Facade targets an entire subsystem (with potentially many classes, factories and builders). The goal of both is to provide your code with a more palatable API than the original API of the code you are Adapting/Facading.
and theFool(i dont really want to call you that)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Feel free to PM suggestions on the PFP website - I've let it stagnate since September while I'm busy on other projects, but I will be getting back to it before long...
. One of our thoughts (AC too) is to have an overview page before digging into the detail - make it easier to stick a toe in to test the water before running off to the pages long tutorial that follows.
My favorite design pattern jump page is The Sacred Elements of the FaithMaugrim_The_Reaper wrote:Feel free to PM suggestions on the PFP website - I've let it stagnate since September while I'm busy on other projects, but I will be getting back to it before long.... One of our thoughts (AC too) is to have an overview page before digging into the detail - make it easier to stick a toe in to test the water before running off to the pages long tutorial that follows.