Hi All:
I like the "of" prefix but I think it might be odd to force the convention
for ALL factories. It might be an English language thing for me.
For example, (picking a made up example) this reads really well to me:
Pair.of(foo, bar) because that what you'd use in spoken English.
OTOH, this does not read well to me: Fraction.of(num, denum); this would be
better: Fraction.from(num, denum)
All of this to say that we should make sure that the factory method "reads
well" for that class. I know it might feel subjective.
I like the idea of a private ctor but it does not have to be unique in my
mind. Sure, it's nice if there is one.
I also like the idea of the ctor being private because we can open it up
later to protected if we want to allow for subclassing.
I would also consider making classes final, especially if the ctor is
private.
Gary
On Thu, Feb 1, 2018 at 7:07 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:
>
>> Hi.
>>
>> IMHO, there are too many accessor and factory methods.
>> We should strive for a lean and consistent API.
>>
>> For the factory methods, I suggest the "of" convention:
>> public static Complex ofCartesian(double re, double im)
>> public static Complex ofPolar(double abs, double arg)
>> And, as syntactic sugar:
>> public static Complex ofCis(double arg)
>>
>
> Those are useful too:
> public ofReal(double re)
> public ofImaginary(double im)
>
>
>> For the accessors:
>> public double re() { return real }
>> public double im() { return imaginary }
>>
>> I'd have
>> public double arg()
>> public double abs()
>> in order to compute the polar coordinates.
>>
>> I'm -0 to have others as syntactic sugar since they are
>> misleading (a.o. when "implying" the read of a field when
>> a computation is performed).
>>
>> WDYT?
>>
>
> In addition to the above, I propose
> * to have a single, "private", constructor:
> private Complex(double re, double im)
> * to remove the "protected" method "createComplex" (
> unless there is a case for inheritance).
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
