On 1/13/14, 1:20 PM, Thomas Neidhart wrote:
> On 01/12/2014 06:46 PM, Phil Steitz wrote:
>> On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
>>> Hi,
>>>
>>> we had some preliminary discussion about changing the
>>> BinominalConfidenceInterval class in MATH-1086.
>>>
>>> Right now the class provides some non-static methods to create various
>>> ConfidenceIntervals, and I was proposing to change them to be static.
>>>
>>> Another option would be to allow sub-classing by defining an interface
>>> (or abstract base class) to create such an interval:
>>>
>>> public interface BinomialConfidenceInterval {
>>>    ConfidenceInterval createInterval(int numberOfTrials,
>>>                                      int numberOfSuccesses,
>>>                                      double confidenceLevel);
>>> }
>>>
>>> With subclasses for the individual methods, e.g. Wilson or
>>> NormalApproximation.
>> I am +1 for this.  Calling conversion of current methods to static
>> 0) and above 1), seems to me there are two other reasonable options:
>> 2) do nothing - leaving the methods non-static preserves extensibility
>> 3) use an abstract class instead of interface - I think we may be
>> getting carried away with preference for this approach and I think
>> it would be silly in this case
>>
>> So my preference order is 1), 0), 2), 3).  I guess TestUtils is OK
>> as the home for the static convenience methods in cases 1), 2), 3).
> Option 3 would make sense to avoid duplicating the checkParameters
> method which is currently used by all the different getXXXInterval methods.

Good point.  Maybe best to just do go the abstract class route then.
>
> But we can also make it package private and static in TestUtils.

Seem unnatural placement, so I guess I am +1 for 3)

Phil
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to