Java Reference
In-Depth Information
public DatabaseLine(final int lineId, final int[] words) {
this.lineId = lineId;
Objects.requireNonNull(words, "words");
if (words.length == 0) {
throw new IllegalArgumentException("no words in this line!");
}
this.words = words;
}
public int getLineId() {
return lineId;
}
public int[] getWords() {
return words;
}
}
This code accomplishes the same thing as the pure object-oriented solution, but with significantly less
code and a clearer flow of processing. If you wanted to insert additional processing at some point (such
as having distinct steps for looking up the text id, line id, and word id), then it is obvious where you would
insert that. And the combination of object oriented and more functional models makes for more concise,
readable code.
A more advanced, more parallel-friendly version of this processing could produce the texts as an object
with a title, year, and a stream of lines with their offset. That object could them be mapped to a text id, and its
stream of lines could be mapped in parallel into line ids, word ids, and then into the database. This would be
a two-stage approach: the first stage would parse the anthology's lines into a stream of these text objects, and
then the second stage would process each of these text objects and their stream of lines. That would be the
natural evolution of this approach, should you need it.
There are two major drawbacks to the post-functional approach, and they both come from the fact that
you have to think in terms of types, mappings between types, and hook functions like
.map
and
.filter
.
The first difficulty is that this simply requires a more abstract and higher order of thinking, so you spend
more time doodling on paper than writing code. There are some developers who find this very unpalatable,
because they just want to keep cranking out code at the speed of thought. Another difficulty with this
approach occurs when the solution does not lend itself to an element-wise solution, such as our rule about
the year signaling the title. In that case, we force a sequential execution and have to work with mutable state,
which reintroduces some of the issues endemic to object-oriented code.
On the other hand, if you want to write a concurrent program with a clear flow of execution that still
gets the primary benefits of object-oriented code, then the post-functional paradigm is what you want. As
long as your application - or even your segment of an application - has a clear flow and a clear mapping
between the steps in the flow, then this is a great paradigm to use. That occurs very often, which is why the
introduction of lambdas and post-functional programming in Java is so exciting. It's why this topic exists.
