Get Time
Search | Watch Thread  |  My Post History  |  My Watches  |  User Settings
View: Flat (newest first)  | Threaded  | Tree
adapt a concrete class | Reply
Please note that I use the wording "API" rather than "interface" (as GoF does) since the adapter pattern does not depend on an actual interface implementation (as used in Java/C#).

Does it mean if the IValidator in your example is replaced by a concrete IValidator implementation (e.g. PhoneValidator), it is still called 'Adapter Pattern' ?

Re: adapt a concrete class (response to post by Standlove) | Reply
If IValidator became PhoneValidator and the implements association becomes an extends association - then yes, it would still be considered an adapter because it's purpose is to adapt the IRule to the PhoneValidator API.
Re: adapt a concrete class (response to post by Pops) | Reply
I don't quite follow your words after and.
Does 'implements association' (or 'extends association') mean the association from DataValidatorAdapterRule to IValidator (or PhoneValidator) ?

Re: adapt a concrete class (response to post by Standlove) | Reply
Let me make sure I understand you scenario. You are saying that if the following is true:
There is a concrete class called PhoneValidator and an interface called IRule. You want to create an adapter to adapt the PhoneValidator API to an IRule API. If that is correct, yes you can by providing a subclass of the PhoneValidator that calls the IRule API in place of the associated PhoneValidator methods (ie you override the methods of PhoneValidator to call IRule instead). This would definately be considered an adapter because you are adapting one API to another (ie you can use an IRule implementation in the places where a PhoneValidator is used).

What I meant by and was that the DataValidatorAdaperRule currently implements the IValidator interface. To make the above come true (where the IValidator is replaced by a concrete PhoneValidator class), you'd also need to change the associated from an implements to an extends (because you need to create a subclass of PhoneValidator now). Is that clear or am I mumbling more?

Btw - haven't seen you in the forums recently - welcome back!
Re: adapt a concrete class (response to post by Pops) | Reply
Read your article a third time to make sure I get it correct =)

I want to create a PhoneRule, which implements IRule and will call PhoneValidator to validate the data. According to what you said, it should be an adapter pattern.

And DataValidatorAdaperRule implements IRule interface rather than IValidator interface ...

Thanks, and thanks for your tutorial :)
Re: adapt a concrete class (response to post by Standlove) | Reply
Ah - I see. Well this is where it comes down to intent. Is the intent of the class simply to adapt the methods of the IRule interface to those defined in the PhoneValidator? If the answer is yes, then it would absoluetly be an adapter pattern.

However, the more the PhoneRule does outside of that context, the less it becomes like an adapter and the more like another strategy implementation of IRule. Example: if PhoneRule not only validates using PhoneValidator but also provides services like, Phone lookups (or some other phone related service) - then I'd say it's more like a complex object, that happens to use PhoneValidator to fulfill part of it's purpose, than it is an adapter...

See the difference (ie it's based on the intent)?
Re: adapt a concrete class (response to post by Standlove) | Reply
When we should use Adapter pattern

  • When client wants to interact with existing system using incompatible interface.

  • When a new system wants to interact with legacy(old) system using new interface which is not compatible with interface of legacy system.

  • When you want to use a 3rd party framework or library whose interface is incompatible with your system.

Advantages of Adapter Pattern Design Pattern

  • Two classes having incompatible interfaces can interact with each other using an Adapter class.

  • It promotes reusability of existing system. A class can be accessed by multiple systems using different interfaces and Adapters.

Source : Adapter Design Pattern in Java