[
https://issues.apache.org/jira/browse/FLUME-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531552#comment-13531552
]
Mike Percy commented on FLUME-1780:
-----------------------------------
Let's take serializers as an example.
{noformat}
public interface EventSerializer {
public interface Builder {
public EventSerializer build(Context context, OutputStream out);
}
}
{noformat}
The EventSerializer.Builder interface guarantees that it will give you back a
working EventSerializer if you provide a Context object (e.g. Configurable) and
an OutputStream. Here is the usage:
{noformat}
Builder builder = Class<? extends
Builder>.forName(builderClassName).newInstance();
EventSerializer serializer = builder.build(context, out);
// serializer is ready for use
{noformat}
The alternative to encapsulating this within the builder is to provide a
protocol-based contract on your classes. Here is an example:
{noformat}
EventSerializer serializer = Class<? extends
EventSerializer>.forName(serializerClassName).newInstance();
serializer.init(out);
serializer.configure(context);
// serializer is ready for use
{noformat}
In my opinion, this last idiom makes such plugin classes more complicated to
write correctly and harder to maintain for the following reasons:
# The serializer must maintain state and check the state it's in when
configure() is called. This type of validation often adds a non-trivial amount
of complexity and boilerplate code to the class
# It's not possible to use language safety features like final fields for
configuration options or the OutputStream out field, which simplify programming
I realize that these are design considerations, and are therefore subjective.
But I hope this clarifies my motivations when designing these APIs in this way.
> Interceptors and serializers should not expect users to supply builders or
> specify the builders in configuration
> ----------------------------------------------------------------------------------------------------------------
>
> Key: FLUME-1780
> URL: https://issues.apache.org/jira/browse/FLUME-1780
> Project: Flume
> Issue Type: Bug
> Reporter: Hari Shreedharan
>
> Forcing a programming model on users is not a good thing to do. We have
> already specified the interfaces, that should be enough
--
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
