On 01/14/2014 09:16 PM, Phil Steitz wrote:
> 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)

ok good, I will then make the change.

Thomas

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

Reply via email to