[ 
https://issues.apache.org/jira/browse/IO-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17811671#comment-17811671
 ] 

Gary D. Gregory commented on IO-846:
------------------------------------

I'm afraid I have to disagree. I see multiple goals using builders:
 # Avoid constructor inflation, especially in the context of NIO, where most of 
my apps use Paths internally no matter what kind of stream or reader I want to 
create. I should be able to create a stream or reader simply and in a readable 
manner. I'm looking at you {{FileWriterWithEncoding}} and {{XmlStreamReader}} ;)
 # Consistency across Commons IO. This is instead of an arbitrary "large number 
of arguments". What's "large"? According to what metric?
 # A pattern for contributors and maintainers to follow when creating a new 
Stream or Reader to avoid constructor inflation. A new class can avoid 
constructor inflation by providing a single private constructor and builder. 
The private constructor can be updated at will.

> Undeprecate RandomAccessFileInputStream constructors, deprecate the builder
> ---------------------------------------------------------------------------
>
>                 Key: IO-846
>                 URL: https://issues.apache.org/jira/browse/IO-846
>             Project: Commons IO
>          Issue Type: Bug
>          Components: Streams/Writers
>            Reporter: Elliotte Rusty Harold
>            Priority: Major
>
> The Builder pattern is actively negative here. It introduces at least one 
> runtime failure mode (not setting the underlying file) that is a compile time 
> error with a constructor. The constructors are simpler, more obvious, and 
> less error prone. 
> The builder pattern is **not** preferred to constructors in all cases. It is 
> a non-standard idiom outside the Java language that is appropriate when:
> 1. There are a large number of arguments.
> 2. At least two of the arguments have the same type so there is a real risk 
> of swapping them. 
> 3. Any combination of arguments is allowed.
> All three of those conditions are false in this case. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to