On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey <rob.j.godf...@gmail.com>wrote:

> On 23 January 2013 17:36, Phil Harvey <p...@philharveyonline.com> wrote:
> >
> > As part of the Proton JNI work, I would like to remove all calls to
> > proton-j implementation constructors from "client code".  I intend that
> > factories will be used instead [1], thereby abstracting away whether the
> > implementation is pure Java or proton-c-via-JNI.
> >
> > I'd like to check that folks are happy with me making this change, and to
> > mention a couple of problems I've had.
> >
> > In this context, "client code" is anything outside the current
> > sub-component, where our sub-components are Engine, Codec, Driver,
> Message
> > and Messenger, plus each of the contrib modules, and of course third
> party
> > code.
> >
> > To enforce this abstraction, I am planning to make the constructors of
> the
> > affected classes package-private where possible.  I believe that,
> although
> > third party projects might already be calling these constructors, it is
> > acceptable for us to change its public API in this manner while Proton is
> > such a young project.
> >
>
> +1 to all of the above
>
> >
> > Please shout if you disagree with any of the above.
> >
> > Now, onto my problem.  I started off with the
> org.apache.qpid.proton.engine.
> > impl package, and found that  o.a.q.p.hawtdispatch.impl.AmqpTransport
> calls
> > various methods on ConnectionImpl and TransportImpl, so simply using a
> > Connection and Transport will not work.  I don't know what to do about
> > this, and would welcome people's opinions.
> >
>
> So, the simplest change would be to change the factories to use
> covariant return types
>
> e.g. EngingFactoryImpl becomes:
>
>     @Override
>     public ConnectionImpl createConnection()
>     {
>         return new ConnectionImpl();
>     }
>
>     @Override
>     public TransportImpl createTransport()
>     {
>         return new TransportImpl();
>     }
>
>
> ... etc
>
> Code that requires the extended functionality offered by the pure Java
> implementation can thus instantiate the desired Factory directly.
>

What's the point of going through the factory in this scenario rather than
directly instantiating the classes as Hiram suggests? Is there some class
of thing the factory would/could do that the constructor can't/shouldn't?

A second refinement might be to actually separate out the interface
> and implementation within the pure Java implementation so that we have
> a well defined "extended" Java API.  This interface could then be the
> return type of the factory.
>

Maybe I'm misunderstanding, but what's the point of using an interface here
if you're still locked into the pure Java impl? Are you expecting to swap
out that impl under some circumstances?

--Rafael

Reply via email to