Hello. > >> > >>What is the group's feeling on factory classes? +1 from me (obviously) > >> > >+1 for me, I like factories. > > -0. We used factories and removed most of them. In fact, what we > removed was when factories are used to hide implementation and only > an interface and a factory are available to users. This is a > different cases. > > There are other places too where we still have some factories, even > in new code (an example would be Region in the geometry package if I > remember well).
-1 for a factory. [Note that I haven't thought at all about use-cases (and thus at how a factory would be best to answer those unspecified needs). Please give some examples.] We indeed removed several factories that IMO were an hindrance because they were hiding important specifics of algorithms. [E.g. there was a root solvers factory that would return one of the solvers which CM provides. How is it the role of a library to decide which solver is good for a given user?] Factories are undisputably good when they generate the *one* correct implementation (cf. the well-known example of GUI widgets that must correspond to the chosen "theme" or the current low-level graphics primitives). In CM, there is a factory that creates one or another kind of matrix, depending on the number of entries. [This seems reasonable but, the threshold being somewhat arbitrary, I would be interested to know how many applications rely on this automatic choice of implementation.] However, in this case, what would a factory bring? When the user knows what he wants, I much prefer explicit instantiation because the code clearly shows what class is being used (obviously): PivotingQRDecomposition qr = new PivotingQRDecomposition(m); vs QRDecomposition qr = QRDecompositionFactory.create(true); or (even worse IMHO) QRDecomposition = DecompositionFactory.createQRDecomposition(true); where the boolean parameter is assumed to select whether the "pivoting" feature is enabled or not. IIUC, there are things you can query from a "PivotingQRDecomposition" that you cannot from the "FastQRDecomposition", then when you get the interface "QRDecomposition", you've lost these additional features. And if you impose that the interface contains them, then if you request the "fast" implementation, and then query the "pivoting" features, what happens? Also, since each decomposition (LU, SVD, ...) provides different methods (except the common "getSolver"; see my previous post), it is fairly clear that a generic "Decomposition" interface would not be useful at all. I argue again that, at the CM level, there isn't enough context to make a uniformly right decision. Applications that would benefit from a factory can of course create them at their level. Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
