[
https://issues.apache.org/jira/browse/UIMA-2874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13654469#comment-13654469
]
Richard Eckart de Castilho commented on UIMA-2874:
--------------------------------------------------
The API-style you describe is called "Fluent"-style [1]. That's a style fitting
well with the builder pattern [2].
I don't suggest to use either of them. My motivation comes from totally
different angles:
* the CAS is overloaded
* serialization is a transformation concern, while I see the CAS is mainly a
data object
* having static methods in a utility class is convenient for users (cf.
uimaFIT), but it's arguably not the best design for a framework
** static methods can only respect static configurations
** static methods cannot implement an interface
** static methods are a dead-end in extensible (object-oriented) design
* constructors with arguments are (in my opinion) good for convenience, but
there should be a no-args constructor
** I am regularly in situation where I need to instantiate classes dynamically.
Let's say we have an application where one can choose to serialize as "XMI",
"XCAS" or "binary". Assuming that every serializer has a no-args constructor
and that all configuration settings are filled with sensible defaults, that's
easy. If every serializer has another interface and different constructors, I
need a big if/else construct and its more work to integrate new serialization
mechanisms.
** it is annoying to instantiate classes with constructor args in frameworks
like Spring, because constructor args are "anonymous". Only recently and only
when compiled with debug information enabled, it is possible to access the name
of a method or constructor argument via reflection. Bean properties
(setter/getter) have a name and provide a standard convention for interacting
with Java objects.
** per chance, I came across a paper recently, claiming that some people can
work better with APIs that support a create-set-call style [3]
My primary motivation, though, was to make a point in having (de)serialization
of the CAS somehow standardized. It appears to have been historically sprinkled
here and there in the code. Meanwhile, I think there should be enough of it to
do some refactoring and clean it up. A variant which allows controlling common
properties (getter/setter) and methods via an interface can capture the
commonalities while leaving all possible room for serializer-specific
properties/methods. Arguments towards no-args constructors are discussed above
already.
[1] http://en.wikipedia.org/wiki/Fluent_interface
[2] http://en.wikipedia.org/wiki/Builder_pattern
[3] Jeffrey Stylos , Steven Clarke , Brad Myers - Comparing API Design Choices
with Usability Studies: A Case Study and Future Directions”, PPIG (2006) -
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.8525
> binary compression APIs in CAS
> ------------------------------
>
> Key: UIMA-2874
> URL: https://issues.apache.org/jira/browse/UIMA-2874
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 2.4.1SDK
>
>
> Rationalize the CASImpl binary compression APIs; add to the CAS Apis.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
