Mark R. Diggory wrote:
>>
>>
>> That's the real problem -- local variables for methods should not be
>> instance variables and certainly not part of the API (which they are
>> as protected instance variables).
>>
>
> But with that kind of logic one could argue that InnerClasses should
> never be used to encapsulate implementation and classes should never
> delegate to another class to accomplish a task. Factories and Services
> would be very difficult to build. Many of the Factories and
> Implementations throughout the Math package use this approach.
>
> Also, maintaining it outside of the method allows for reusage.
I don't mean to imply that all implementations should be stateless or that
instance variables (including stateful cached instances or even stateless
instances when instantiation is expensive) or inner classes should be
avoided -- only that making the "helper" stats instance variables in this
case makes it look like their state may be linked to the instance, which
it is not, and there is no real overhead in instantiating them, so I would
rather do it locally.
>>
>> Of course, another option would be to move the common code back into
>> StatUtils if these methods are going to be static. That would add
>> efficiency to StatUtils as well.
>>
>
> The only shortfall with that I can think of is in the future I want to
> allow for other implementations of the evaluations (for instance JNI, R,
> Matlab or Mathematica(JLink) evaluations). I'd like to have the API use
> Services to discover which Implementation to use, I fear we loose this
> option when packing all the evaluation methods into StaticUtils. At
> least, we loose the ability to "plug alternate implementations" in
> behind StaticUtils if the implementation is static.
Not if we keep the evaluate() methods in the stats objects and have these
methods delegate (in the default impls) to StatUtils. Then Variance, Mean
et al could be swapped out w/ other impls that do not use the "stock"
numerics collected in StatUtils. Wouldn't that provide the flexibility
that we want?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
|