Striterators
The name Striterator is intended to convey a merging of Stream and Iterator functionality. It captures an impression I had when first exposed to Java of a degree of similarity between an Iterator and an Object stream. Stream-based processing is a very strong idiom and it seemed that it should be possible to provide approach Iterators in a similar way.
Furthermore, while Iterators are presented as supportive of in-memory
object access, streams are naturally considered to map over files and
external connections. This approach appeared arbitrary. For example, if
an ObjectInputStream is only used to deliver a stream of Objects, then
it is trivial to define an Iterator implementation supplied by it. This
acknowledges two things: the similarity of an object stream to an
Iterator and the potential for an Iterator to deliver incremental object
values.
Stream-based processing is presented as composition, with one stream providing input to another with the output representing some transformation of the input. So the first stage in the development of the Striterators was to replicate that pattern, that a Striterator should consume an input Iterator.
This is demonstrated by the default Striterator implementation, such that:
Iterator striter = new Striterator(iter);
results in the striter simply delegating the Iterator implementation to the source Iterator.
The next stage is to identify some standard transformations to provide direct support for.
- The Resolver pattern transforms one object into another.
- The FilterTest pattern filters out invalid objects.
- The Expander pattern expands each original object into many.
- The Appender pattern appends another Iterator.
- The Sorter pattern defines an ordering - requiring eager consumption of the source.
- The Merger pattern mergers two ordered Iterators.
As is often the case when new approaches are used to solving problems, new possibilities become apparent. Sure it is possible to add transformations to a Striterator and then process the resulting Iterator as a code refactoring exercise, but more interesting is that the resulting Iterator can now be passed as a parameter to or returned from a function, or, if passed as a Striterator may have more transformations applied to it.
Recent BigData enhancements to the Striterator patterns have added the potential for manipulation and remote execution by the Striterator transformation stack.
