What's your need for the direct constructor?
-- Rob
On 25 January 2013 15:49, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Let me clarify, I have no problem with adding Factories and using them
> everywhere possible. Just don't take my access away from direct
> constructors.
>
>
> On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey <rob.j.godf...@gmail.com>wrote:
>
>> In general dependency on implementation is bad, dependency on interface is
>> better. One of the problems we've had with Qpid historically is it become
>> hard to test as we have dependencies on implementation everywhere.
>>
>> From an end user perspective the difference is only replacing
>>
>> X x = new X();
>>
>> with
>>
>> X x = XFactory.newInstance();
>>
>> But it makes it a lot easier to properly describe the functionality being
>> returned. For implementation reasons, the concrete class may have public
>> methods that are not intended to be exposed to the application programmer
>> but only to other cooperating classes. To avoid confusion, and to make it
>> clear to us the delta between the "shared" API and the API extensions that
>> we are supporting for the pure Java implementation the interfaces seem like
>> the right way to go for me.
>>
>> The idea is that those who need the extension features will still have a
>> very clear way to get the implementation that provides these, without ever
>> having to cast.
>>
>> -- Rob
>>
>>
>>
>>
>>
>> On 24 January 2013 20:03, Rafael Schloming <r...@alum.mit.edu> wrote:
>>
>> > 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
>> >
>>
>
>
>
> --
>
> **
>
> *Hiram Chirino*
>
> *Engineering | Red Hat, Inc.*
>
> *hchir...@redhat.com <hchir...@redhat.com> | fusesource.com | redhat.com*
>
> *skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
> *
>
> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
