'. '

RequestResponse

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Response Reply)
(Response Reply)
Line 8: Line 8:
public static final class Request {
public static final class Request {
-
private Request() {}
+
Request() {}
public int getArg1();
public int getArg1();
Line 15: Line 15:
public static final class Response {
public static final class Response {
-
private Response() {}
+
Response() {}
public void addResult(int r);
public void addResult(int r);
Line 22: Line 22:
}
}
</source>
</source>
 +
 +
==== Evolution Story ====
 +
 +
The evolution of the whole pattern is based on the assumption that the fixed point of communication with users of the API is the ''ComputeSomething'' interface with its one method that has to be implemented. From this interface we have two evolution paths:
 +
# clients of the API can require more methods to call. those can be added to Request class
 +
# the infrastructure may want to give the clients more richer way to specify return values. This means to add new methods into the Response class.

Revision as of 20:23, 25 June 2008

Response Reply

Design pattern that solves the problem of growing parameters and return values from API methods. Beyond its basic purpose, it can help with delivering multiple results and providing the results in an incremental way, one by one. It also helps a lot with ability to cancel a computation in the middle.

public interface ComputeSomething {
    public void compute(Request request, Response response);
 
    public static final class Request {
        Request() {}
 
        public int getArg1();
        public String getArg2();
    }
 
    public static final class Response {
        Response() {}
 
        public void addResult(int r);
        public void addResult(String[] arr);
    }
}

Evolution Story

The evolution of the whole pattern is based on the assumption that the fixed point of communication with users of the API is the ComputeSomething interface with its one method that has to be implemented. From this interface we have two evolution paths:

  1. clients of the API can require more methods to call. those can be added to Request class
  2. the infrastructure may want to give the clients more richer way to specify return values. This means to add new methods into the Response class.
Personal tools
buy