Oleksiy Stashok wrote:
>>>>
>>>> With Alexey's proposal, we will have to explicitly set those to
>>>> each transport implementation if we want to share component. With
>>>> the current Controller, I suspect this is simpler/less code to
>>>> manage. Also, is the Controller name that confusing so we want to
>>>> rename it TransportManager? I guess yes :-)
>>> During the meeting I agree, that we need to have something like
>>> Controller to share what is possible to share among different
>>> transports.
>>> Though I think this class should be optional to use - just in case
>>> of several transports.
>> But I need someplace to create an instance of a transport. Why not do
>> this in the
>> TransportManager? Something like:
>>
>> TransportManager.makeXXXTransport( ... )
>>
>> or
>>
>> TransportManager.instance().makeXXXTransport( ... )
>>
>> I'd rather avoid explicit calls to new to create a transport:
>> new always requires creating a new instance, whereas factory
>> methods can be more flexible.
> I agree with idea you have such a factory, just have 2 concerns:
> 1) should we have "make" method for each transport?
Yes: that's what I meant by "XXX" (replace XXX with TCP and UDP to
create two methods).
> 2) If developer will want to extend existing transport or implement
> new one - he will need also provide own TransportManager implementation?
I would NOT support extending an existing transport. It is much harder
to design and specify a class
for subclassing. Instead, ask why do users WANT to extend a transport,
and provide ways
of achieving those requirements, typically by having the user implement
an interface and
register it with the transport.
I've seen this in many places. Designing a class to be properly
subclassable takes a lot of
effort, and it is hard to get right for a large user community. The
worst problem is that
the subclasses users write will almost inevitably start using some
internal detail of the class
that you don't want them to, and then a supposedly invisible
implementation change breaks
someone's code that you don't even now.
In generally, only use subclassing when you completely control the use
of the subclasses.
I generally don't use subclasses beyond implementation factoring and
abstract base classes.
As another example, there are almost no places in the CORBA API
(internal or external) where
subclassing of an implementation class is used.
If someone wants to implement a new Transport (say for one of the
low-level Infiniband
protocols, or possibly some Telco ATM switch), we should expect them to
be an expert-level
grizzly implementor, and they should modify the TransportManager code
directly. I don't
think it's reasonable to do more than this, but possibly implementing an
abstract
TransportBase class for code shared in the TCP and UDP cases could be
useful for this.
>
> On other side we can add one more method:
> TransportManager.instance().makeTransportByName(Class<? extends
> Transport>) or something like that.
I don't think we want to do this.
>
> anyway, IMHO, it makes sense to have both possibilities:
> TransportManager & "new", cause for simple usecases, IMHO, it's easier
> and more clear to use "new".
I don't like giving users too many options. There are many APIs in which
you do not directly call
new (for example, everything in CORBA). Stylistically I prefer not to
call new directly as a client of
an API.
Thanks,
Ken.