JaroslavTulach at 12:37, 15 November 2008 - 2008-11-15 12:37:31

←Older revision Revision as of 12:37, 15 November 2008
Line 22: Line 22:
[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns]]
 +
[[Category:APIDesignPatterns:Evolution]]

JaroslavTulach: APIDesignPatterns:RequestResponse moved to RequestResponse - 2008-11-15 12:36:38

APIDesignPatterns:RequestResponse moved to RequestResponse

←Older revision Revision as of 12:36, 15 November 2008

Apidesign at 06:05, 12 November 2008 - 2008-11-12 06:05:13

←Older revision Revision as of 06:05, 12 November 2008
Line 20: Line 20:
Last, but not least, this API pattern supports easy interruption of long computations. The ''Response'' or even the ''Request'' can contain ''boolean isCancelled()'' method which may allow the provider of the ''compute'' method implementation to check this value and exist earlier, before everything is computed. In addition to this, the ''addResult'' methods can check this flag themselves, and potentially abort the computation by their own, usually by emitting some checked exception.
Last, but not least, this API pattern supports easy interruption of long computations. The ''Response'' or even the ''Request'' can contain ''boolean isCancelled()'' method which may allow the provider of the ''compute'' method implementation to check this value and exist earlier, before everything is computed. In addition to this, the ''addResult'' methods can check this flag themselves, and potentially abort the computation by their own, usually by emitting some checked exception.
 +
 +
[[Category:APIDesignPatterns]]

JaroslavTulach at 07:28, 24 October 2008 - 2008-10-24 07:28:58

←Older revision Revision as of 07:28, 24 October 2008
Line 1: Line 1:
-
 
+
[[APIDesignPatterns|API 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.
-
[[APIDesignPatterns|API 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.
+
<source lang="java" snippet="grow.request.response"/>
<source lang="java" snippet="grow.request.response"/>

JaroslavTulach at 07:28, 24 October 2008 - 2008-10-24 07:28:45

←Older revision Revision as of 07:28, 24 October 2008
Line 1: Line 1:
-
== 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.
+
[[APIDesignPatterns|API 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.
<source lang="java" snippet="grow.request.response"/>
<source lang="java" snippet="grow.request.response"/>

JaroslavTulach: First use of code snippets database - 2008-07-06 20:41:01

First use of code snippets database

←Older revision Revision as of 20:41, 6 July 2008
Line 3: Line 3:
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.
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.
-
<source lang="java">
+
<source lang="java" snippet="grow.request.response"/>
-
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);
+
-
}
+
-
}
+
-
</source>
+
==== Evolution Story ====
==== 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:
+
The evolution of the whole pattern is based on the assumption that the fixed point of communication with users of the API is the ''Compute'' 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
# 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.
# 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.

JaroslavTulach: /* Additional Attributes */ - 2008-06-25 21:14:12

Additional Attributes

←Older revision Revision as of 21:14, 25 June 2008
Line 36: Line 36:
Related to this, the API pattern allows the infrastructure, which provides the ''Response'' class, to process the results sooner before they are fully computed. The ''compute'' method can still be running, incrementally computing its results, and yet, the infrastructure may process the already generated values.
Related to this, the API pattern allows the infrastructure, which provides the ''Response'' class, to process the results sooner before they are fully computed. The ''compute'' method can still be running, incrementally computing its results, and yet, the infrastructure may process the already generated values.
 +
 +
Also, if you happen to have multiple providers, it is possible to feed them with the same ''Request'' at once, in different threads and collect their responses on a one by one basis, using those that are delivered faster.
Last, but not least, this API pattern supports easy interruption of long computations. The ''Response'' or even the ''Request'' can contain ''boolean isCancelled()'' method which may allow the provider of the ''compute'' method implementation to check this value and exist earlier, before everything is computed. In addition to this, the ''addResult'' methods can check this flag themselves, and potentially abort the computation by their own, usually by emitting some checked exception.
Last, but not least, this API pattern supports easy interruption of long computations. The ''Response'' or even the ''Request'' can contain ''boolean isCancelled()'' method which may allow the provider of the ''compute'' method implementation to check this value and exist earlier, before everything is computed. In addition to this, the ''addResult'' methods can check this flag themselves, and potentially abort the computation by their own, usually by emitting some checked exception.

JaroslavTulach: /* Evolution Story */ - 2008-06-25 20:49:02

Evolution Story

←Older revision Revision as of 20:49, 25 June 2008
Line 28: Line 28:
# clients of the API can require more methods to call. those can be added to Request class
# 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.
# 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.
 +
 +
==== Additional Attributes ====
 +
 +
This API pattern naturally solves the problem of multiple return values from a method. Java does not support that easily, while with ''Response'' class, it is easy to add new result methods into it. Allowing type safe extensibility of return types.
 +
 +
Also this API pattern supports incremental return values, as ''compute'' method can work in a loop and add one result by another into the ''Response'' class, feeding it by as many results as possible.
 +
 +
Related to this, the API pattern allows the infrastructure, which provides the ''Response'' class, to process the results sooner before they are fully computed. The ''compute'' method can still be running, incrementally computing its results, and yet, the infrastructure may process the already generated values.
 +
 +
Last, but not least, this API pattern supports easy interruption of long computations. The ''Response'' or even the ''Request'' can contain ''boolean isCancelled()'' method which may allow the provider of the ''compute'' method implementation to check this value and exist earlier, before everything is computed. In addition to this, the ''addResult'' methods can check this flag themselves, and potentially abort the computation by their own, usually by emitting some checked exception.

JaroslavTulach: /* Response Reply */ - 2008-06-25 20:23:34

Response Reply

←Older revision Revision as of 20:23, 25 June 2008
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.

JaroslavTulach: /* Response Reply */ - 2008-06-25 19:54:04

Response Reply

←Older revision Revision as of 19:54, 25 June 2008
Line 3: Line 3:
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.
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.
-
TBD...
+
<source lang="java">
 +
public interface ComputeSomething {
 +
public void compute(Request request, Response response);
 +
 
 +
public static final class Request {
 +
private Request() {}
 +
 
 +
public int getArg1();
 +
public String getArg2();
 +
}
 +
 
 +
public static final class Response {
 +
private Response() {}
 +
 
 +
public void addResult(int r);
 +
public void addResult(String[] arr);
 +
}
 +
}
 +
</source>