Consider a function that collects and returns a list of results. It might look like this:<\/p>\n
Or even better, this, so it could use anything that implements Iterable<>:\n<\/p>\n
However, storing the results in a container which is then returned may be inefficient for the application. It may be better to enable the calling code to act immediately on each collected result rather than first waiting for all results to be collected and stored. If that were possible..<\/p>\n
One way to avoid an intermediate list is for the collecting function to construct a custom Iterable<> object, which constructs Iterator<> objects that contain the collecting logic. Each execution of next() calculates the next value and returns it straight away for the calling code.<\/p>\n
The difficulty for the programmer is that this may require a significantly different structure of the collecting code. This code has to store any state from result to result as private variables inside the iterator. Call stack is reset with each result, so algorithms that use recursion are not possible.<\/p>\n
More convenient for the programmer would be a technique that allows the collecting code to keep control of the machine state during the collecting process.<\/p>\n
C# has ‘yield return’ which allows a function to be structured exactly as if it is building a list. It may keep its own state in local variables and the call stack, but still present each value to the calling code immediately as it is found.<\/p>\n
Java doesn’t have yield return, but another pattern that could be used is this:<\/p>\n
Where ResultHandler<\/b><> is a simple interface to an object invoked by the collecting code to return individual results as they are collected.<\/p>\n It is left up to the calling code what ResultHandler<> implementing object to supply, and how to handle the data. Anonymous classes would be quite neat here. For instance, a caller could output the results to a console like so:<\/p>\n The collect() function may abort the collecting operation part way through by throwing a CollectionAbortedException.<\/p>\n The disadvantage to this approach is that it is a little less convenient from the perspective of the calling code. The function has a novel pattern, taking ResultHandler<> as a parameter rather than the more familiar Iterable<> as a return value. Logic has to be embedded inside an anonymous or specially constructed ResultHandler<> class.<\/p>\n Unlike the case of returned Iterables, the calling code can not use ‘for each’ loops on the result. Nor can it store or pass around the Iterable<> to other systems as a parameter.<\/p>\n A best-of-both-worlds solution would allow a collecting method based on ResultHandler<> to be automatically adapted at run time to an implementation based on Iterable<>. A data-collecting function implemented in this form (convenient for the collecting code) …<\/p>\n .. would be adapted into this form (convenient for the calling code)..<\/p>\n This would provide the same benefit C# programs get from yield return. Namely, the ability for both<\/i> collecting code and calling code to have their own machine state and callstack control throughout the entire collecting and processing operation. It is not necessary for either side to separate logic into methods inside anonymous classes. Collecting code can use complex recursion algorithms. Calling code can store and defer use of the Iterable<> used to collect results, or pass them as parameters to other functions.<\/p>\nSolution : The yield adapter<\/h3>\n