Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of thomas.neidhart@gmail.com
 designates 74.125.82.178 as permitted sender)
Message-ID: <52D4589D.8020109@gmail.com>
Date: Mon, 13 Jan 2014 22:20:29 +0100
From: Thomas Neidhart <thomas.neidhart@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Suggestion to refactor BinomialConfidenceInterval
References: <52D2A0B1.1020303@gmail.com> <52D2D4FC.2050607@gmail.com>
In-Reply-To: <52D2D4FC.2050607@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

But we can also make it package private and static in TestUtils.

Thomas

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