On Thu, Oct 06, 2011 at 02:56:28PM -0500, Greg Sterijevski wrote: > Yes, this application would be similar to the ones you nixed. It would be a > factory returning an abstract class, with the appropriate methods throwing > exceptions (like getRank for the non-pivoting version-as Ted mentions in a > later entry in this blog). > > As Ted asks, what is the issue with this?
What I'm asking is: What is the issue with 2 concrete classes (and possibly an abstract base class, if there is some code to share)? [As Ted pointed out, the CM design is not based around factories (which is fine IMO until proven otherwise); changing that would require a strong argument and should lead to a complete revision of the basic layout of the library, in order to be consistent. Maybe for 4.0 :-).] To stretch the argument, why not create a "UniversalDecomposition" class with all the methods in it: getCholeskyL() getLuL() getLuU() getLuP() getQrQ() getQrR() getQrH() getSvdU() getSvdS() getSvdV() ... and throw "UnsupportedOperationException" as necessary? Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
