Given the Proton class doesn't require the user to know which implementation they are using (but allows them to explicitly ask for a particular implementation type if they so desire) I'm a little confused how adding the requirement for the user to instantiate an implementation specific class actually helps the user. Am I missing something? There really is no need for a user to know about factories, etc...
-- Rob On 2 August 2013 15:13, Rafael Schloming <[email protected]> wrote: > On Fri, Aug 2, 2013 at 4:44 AM, Phil Harvey <[email protected] > >wrote: > > > I agree that o.a.q.p.Proton is, overall, an improvement. I was partly > > responsible for creating the ProtonFactoryLoader and XXXFactory classes, > > and acknowledge that they make life too hard for the user. > > > > This was a result of trying to meet the following design goals: > > 1. User code should not need to have a compile-time dependency on any > > proton-c/j/jni classes. Given our current separation of the proton-api > > from the proton-impl/proton-jni modules, it means user code should only > > depend on proton-api at compile-time. > > 2. Classes from the various "top level packages", such as engine, > messenger > > etc, should be kept separate unless they really need to be together. > > > > I still believe in goal 1 (though this will be discussed at greater > length > > on the related thread [1]), but am relaxed about item 2. > > > > Thanks for describing the goals, it's helpful to have them written down. I > personally don't feel that the Proton class is violating (2) in an > important way so long as engine and messenger remain otherwise unentwined. > > I generally agree with (1) also, however I think it could use some further > refinement. At the root of (1) is the desire to make it clear and obvious > to developers if/when they are depending on the characteristics of a given > implementation rather than on a more abstracted interface. Probably the > most common example of this sort of thing within Java would be typical > collections usage of interface/impl splits, e.g.: > > List foo = new ArrayList(); > ArrayList bar = new ArrayList(); > LinkedList baz = new LinkedList(); > > The suggested pattern for the Proton class would be following this pattern > exactly: > > Proton p = new ProtonJ(); > ProtonJ pj = new ProtonJ(); > ProtonC pc = new ProtonC(); > > Now this pattern of course doesn't really speak to classpaths at all. The > classpath issue is really entirely orthogonal to the interface/impl > distinction. Right now we have separate classpaths, but a muddled > interface/impl distinction since the impl jar adds new interfaces into > packages belonging to the API jar, and the API jar has stuff in it that is > really part of a specific impl. Likewise, you can have a clear > interface/impl distinctions within a single jar as is the case with java > collections. > > I'd argue that the classpath thing is really a distinct goal/requirement > and is really more about a discovery mechanism for independent or third > party implementations. I don't personally feel that this is a necessary > requirement for us at this point, but I'm fairly relaxed if other people > would like to support it. > > Given the above refinement of (1) into (1a) interface/impl split and (1b) > independently implementable API, I would find it a bit odd to put the > ProtonJ/ProtonC classes into the API package since that would introduce a > dependency from the API package back to those impls (even if its only a > runtime dependency) and would effectively give those impls an elevated > position which in some sense is fine, but also seems contrary to the > independently implementable notion in the first place. It seems like what > you'd want in the API package is purely a generic discovery mechanism that > would work for any implementation. > > As I said above, I don't feel like such a discovery mechanism is really a > requirement for us right now. I think actually having a complicated > discovery/factory pattern is in some ways detrimental as it creates a > barrier to entry for all users when most don't care about the flexibility > it offers (at least right now) and if they do care about that flexibility > it is easy enough for them to build their own. In fact modulo exception > handling it is really just one extra line of code: > > Class impl = Class.forName(System.getProperty("blah")); > Proton p = (Proton) impl.newInstance(); > > So I'd personally say go for the simple interface/impl split pattern that > everyone knows and is used to and don't worry about a generic discovery > mechanism until we actually have enough implementations for it to be > warranted. > > --Rafael >
