On 09/02/17 04:02, Peter Ansell wrote:
Not all fluent configuration APIs are "builder patterns". By that I
mean that you can have a "return this" convention for the builder with
mutable fields without it building or cloning new objects.
A builder pattern is characterised by a terminal method returning a
new instance of an object, avoiding the archaic multiple-constructor
pattern. It is also generally fluent, but there is no requirement that
a builder be fluent. There is also no requirement that the result of
the build() method be fully immutable. I.e., in this case, it could be
a parser object with mutable parsing state, even though its
configuration fields are likely to be immutable.
You can do all of that without a difficult to define and implement
"clone" method, and without reconfiguring multiple builder objects in
the same way.
For example, your code could change to:
JenaRDFParserFactory factory = new JenaRDFParserFactory()
.contentType(RDFSyntax.TURTLE)
.target(g1);
factory.parse(Path);
where .parse is a terminal method that creates a new parser object and
parses the given "Path" immediately, without the typical build method.
However, you could also support a "build" method. The reason for
naming it a Factory is to make it obvious that you aren't setting
methods on an actual parser, just setting up for one. In this case the
parser itself is only an internal object, and may not even be on the
API
I am not sure how the Future fits a specific use case though, as it
would not return an actual result, as the results are emitted into the
graph as directed by .target(g1). Not everyone wants parsing to spawn
off a new task/thread, particularly if they have maximum latencies to
maintain for service level agreements, and threads may not be able to
be consistently spawned within those time frames.
parse as a terminal makes sense to me. Maybe setting source and
destination at the point of parsing.
A parser (presumably we are talking streaming parsers) is a process that
takes an InputStream and has a handler for results. The
XRDFParserFactory does not have to set the source and destination though
it may be useful to be able to as an additional feature layered over the
the top of the basic operation of parse(src, dest).
Much the same for Future - that's one model for parsing but it's quite
natural to do it synchronously as well.
I guess my real question is what it the lowest level abstraction you are
aiming for?
(I didn't get from the javadoc is source() can be called multiple times
and if it is, what happens - e.g. prefix and blank node labels).
Andy
... feeling inspired to do try this for Jena because of
recent requests ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
