I have always heard the adapter pattern referred to like this: the adapter pattern is used to extend an interface to meet new requirements, without refactoring legacy code, plus being providing the ability to leverage existing code where applicable.
Suppose some legacy developer has written an interface:
public interface IName
{
string FirstName
{
get;
set;
}
string LastName
{
get;
set;
}
string MiddleName
{
get;
set;
}
string FullName(string firstName, string lastName, string MiddleName)
{
}
}
And for what you want to do, interfaceA almost meets your requirments. Well, you could change interfaceA, to meet your requirements, but interfaceA is in 50% of the objects, used in version 1.1 through 1.9 and you are now writing code for the 2.0 beta.
You could use the adapter pattern (as I know it) to extend interfaceA.
For example, suppose you need to add two fields and a new method, you could just say:
public interface IProperName:IName
{
string Suffix
{
get;
set;
}
string Prefix
{
get;
set;
}
string LastFirstMiddle(string firstName, string lastName, string MiddleName)
{
}
string ProperName(string prefix, string prefix, string firstName, string lastName, string middleName)
{
}
}
You could also have legacy code that worked with Employee objects, that Implement IName, like so: void FormatName(IName currentName). Your old objects that implement IName would look like this:
public class Employee: IName
{
#region IName Members
public string FirstName
{
get
{
// TODO: Add Employee.FirstName getter implementation
return null;
}
set
{
// TODO: Add Employee.FirstName setter implementation
}
}
public string LastName
{
get
{
// TODO: Add Employee.LastName getter implementation
return null;
}
set
{
// TODO: Add Employee.LastName setter implementation
}
}
public string MiddleName
{
get
{
// TODO: Add Employee.MiddleName getter implementation
return null;
}
set
{
// TODO: Add Employee.MiddleName setter implementation
}
}
public string FullName(string firstName, string lastName, string MiddleName)
{
// TODO: Add Employee.FullName implementation
return null;
}
#endregion
}
Any your new classes that deal with your new version could look like this:
public class Client: IProperName
{
#region IProperName Members
public string Suffix
{
get
{
// TODO: Add Client.Suffix getter implementation
return null;
}
set
{
// TODO: Add Client.Suffix setter implementation
}
}
public string Prefix
{
get
{
// TODO: Add Client.Prefix getter implementation
return null;
}
set
{
// TODO: Add Client.Prefix setter implementation
}
}
public string LastFirstMiddle(string firstName, string lastName, string MiddleName)
{
// TODO: Add Client.LastFirstMiddle implementation
return null;
}
public string ProperName(string prefix, string prefix, string firstName, string lastName, string middleName)
{
// TODO: Add Client.ProperName implementation
return null;
}
#endregion
#region IName Members
public string FirstName
{
get
{
// TODO: Add Client.FirstName getter implementation
return null;
}
set
{
// TODO: Add Client.FirstName setter implementation
}
}
public string LastName
{
get
{
// TODO: Add Client.LastName getter implementation
return null;
}
set
{
// TODO: Add Client.LastName setter implementation
}
}
public string MiddleName
{
get
{
// TODO: Add Client.MiddleName getter implementation
return null;
}
set
{
// TODO: Add Client.MiddleName setter implementation
}
}
public string FullName(string firstName, string lastName, string MiddleName)
{
// TODO: Add Client.FullName implementation
return null;
}
#endregion
}
So whats the point?
- We didnt need to refactor tons of code, nor did we change any legacy implementation
- We DID make use of existing code
- We DID keep our code backward compatible
If we refer back to: void FormatName(IName currentName), we can do this:
IProperName client = new Client();
IName employee = new Employee();
FormatName(client);
FormatName(employee);
So anyway, thats my take on the adapter pattern.
