Available at http://www.livejournal.com/users/trajano/24452.html

This is a refactoring I generally do, but I can't seem to find it in www.refactoring.com, it might be an anti-pattern for what I know, what do you think? Also the refactoring link at the note below does not exist yet from what I know since I have to write it still.

objectB.setA(getA(objectA));
objectB.setB(getB(objectA));

|
v

ObjectAdapter adapter = new ObjectAdapter(objectA);
objectB.setA(adapter.getA());
objectB.setB(adapter.getB());
Motivation
Objects that are as simple as Strings or as complex as HttpServletRequest have data that we need to retrieve. However, we need to get specific pieces of data either by using the String.substring() or HttpServletRequest.getAttribute() methods. The direct approach forces an understanding on the how the data is stored in the objects.

The Adapter design pattern is used to wrap an existing object with another object that provides methods that would be named closer to what the client would need and limits the possible inputs to the actual object to what clients would normally need so developers do not have to know which part to get from the data.

Mechanics
Determine the object to be wrapped.
Create a new adapter class that has a constructor with one parameter, the object that needs to be wrapped.
Add a private final field to the adapter class with the type of object that needs to be wrapped.
In the adapter class constructor assign the field with the value from the parameter.
In the client code place the code to create the adapter in. Then test to ensure it is working properly.
Determine a data extraction method used in the client code.
Create a new method that performs the data extraction method into the adapter class.
Replace the client code that used to perform the extraction with the method from the adapter class.
Test.
Add more methods to the adapter for any calculation instance.

Example
Before refactoring.

public class ClassA {
  public void someMethod(String data) {
    Persister.saveData(getId(data), getName(data));
  }
  private String getId(String data) {
    return data.substring(0,4);
  }
  private String getName(String data) {
    return data.substring(5,10);
  }
}

after refactoring

public class ClassA {
  public void someMethod(String data) {
    DataAdapter adapter = new DataAdapter(data);
    Persister.saveData(adapter.getId(), adapter.getName());
  }
}

public class DataAdapter {
  private final String data;
  public DataAdapter(String data) {
    this.data = data;
  }
  private String getId() {
    return data.substring(0,4);
  }
  private String getName() {
    return data.substring(5,10);
  }
}Notes
In some cases all the data is needed by clients so it might be useful to move the code for the getters to be performed during construction rather than on demand. Please see "Move getter logic to constructor" refactoring.

I would probably call it a Proxy rather than an Adaptor. A Proxy typically wraps around an object to constrain access and/or alter its behaviour. An Adaptor usually involves legacy (difficult-to-change) classes on either side, which isn't the issue here.

I don't remember seeing it in Fowler's Refactorings, but it's certainly a useful refactoring to make.

A Proxy would preferably implement the same interface as the object it gives access to, so that the user won't know it's a proxy. Proxy will not necessarily wrap around an object, but mostly control communication with it.

The example shown by Archimedes Trajano is quite what Adapter should do, but I think this precise use is really between Adapter (adapting an exsting interface to a new system), Facade (providing simple meaningful access to an object hierarchy) and Decorator (adding functionnality to the object).

What do you think?

I agree with Guillaume Bertrand.

While such "patterns" can be useful, this particular one increases complexity (an added class per appliance) which should have been mentioned as a liability.

agreed, this should be used when slightly more complex extraction logic is required. more code = harder to maintain

One of the things I think this can be used is for the HttpServletRequest object in which there are several places to get the data: session, attributes, parameters.

Rather than having every class know where to get the data from a map and cast it to the appropriate type, it can be performed on a single place: the adapter.

Maybe there is be more code to maintain, but with good packaging this refactoring can be quite useful, either for complex objects or not.