Hi Venkat, Le 25/06/2014 06:21, venkatesha murthy a écrit : > The Percentile actually uses KthSelector logic and is dependent on only > KthSelector > however the variability part is pivoting strategy. > > Given that both KthSelector and Pivoting are independent we could make them > as utility classes or may be functions with in MathUtils with exposed > interfaces.
+1 > > Heres my opinion: > > First, Move Both PivotingStrategy and KthSelector to utils package as they > can be general purposed +1 > > Secondly, make PivotingStrategy enum implement an interface > PivotingStrategyInterface which allows > random generator to be set and with other necessary methods. This is to > make way for some one who is interested to make a different seed for random > or for a different pivoting strategy itself. Take care that the random generator cannot be set in the enum itself as there is only one instance and it would mean we make an enum mutable, which is really something chilling to me. Do we really need this to be an enum? Couldn't we have only an interface and three regular classes implementations so people can set up their own private RandomPivotingStrategy without fearing other parts of the code would change it? > > Next, make the KthSelector accept a PivotingStrategyInterface rather than > enum +1 > > Next, make Percentile accept a constructed KthSelector and allow it flow > through evaluate and estimate method instead of flowing PivotingStrategy > through estimate method. +1. I understand that in this case you want to replace the withPivotingStrategy by withKthSelector, which is a good thing as it is a more user friendly level of customization. Luc > > What do you think > > thanks > venkat. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
