Hi all,
Thank you all for the valuable feedback, let me try to summarize the rough
agreement:
If there is a builder for class A, then A should:
- Have only private ctor -> force usage of the builder
- Be immutable (no setters)
- Have a public static .builder(required params if not too many) m
> For Piotr's comment 4. I. I agree with Klou that this sounds rather like a
> problem of the builder's usage than a builder problem. I think such a
> scenario can easily be solved by introducing a transfer object.
It could be solved, but that would mean we have some kind of
builder/factory/descr
Hi all,
I would be in favour of the following convention
1. a) static method for builder creation
2. No strict rule because especially for boolean flags it might make sense
to have something like `enableX()` or `withY()` where one doesn't specify a
concrete value.
3. Mutable builders but if there
Hi all,
great to put this code style discussion on the mailing list because I
also have found this style inconsistent in the past.
Regarding Gyula's suggestions:
1. a static method `builder()` I think IDEs are also hightlight methods
with this name
2. I would vote for a more declarative `prop
Hi all,
I agree with Arvid, although for point 2 I would be less strict.
@Piotr, for the side note you mentioned, and from the description you
mention in the mail for example I,
it seems that the need to pass parameters in the build() is not an
inherent need of the build pattern but it
can be mit
Hi all,
I'd like to differentiate between API level builder usage and "internal"
builder usage (for example, test harness).
For API level builder, in general everything goes, as long as it aligns
with user expectations. API level usages are also much more discussed, such
that I'd expect them to b
Hi,
I agree with Dawid, modulo that I don’t have any preference about point 2 - I’m
ok even with not enforcing this.
One side note about point 4. There are use cases where passing obligatory
parameters in the build method itself might make sense:
I. - when those parameters can not be or can n
Hi Gyula,
Thanks for bringing this. I think it would be nice if we have a common
approach to create builder pattern.
Currently, we have a lot of builders but with different tastes.
> 1. Creating the builder objects:
I prefer option a) too. It would be easier for users to get the builder
instance
Hi Gyula,
A few comments from my side.
Ad. 1 Personally I also prefer a static method in the "built" class. Not
sure if I would be that strict about the "Builder" suffix, though. It is
usually quite easy to realize the method returns a builder rather than
the object itself. In my opinion the suff
Hi All!
I would like to start a code-style related discussion regarding how we
implement the builder pattern in the Flink project.
It would be the best to have a common approach, there are some aspects of
the pattern that come to my mind please feel free to add anything I missed:
1. Creating the
10 matches
Mail list logo
