Re: final AbstractIoSession

["Steve Ulrich (proemion)" <st...@proemion.com>]

Hi


Trustin Lee wrote:
> 
> On Nov 29, 2007 10:18 AM, Trustin Lee <tr...@gmail.com> wrote:
>> The reason I changed all the methods in AbstractIoSession to be final
>> was because I didn't see much room for extension there.  If there's
>> any need for extension, I thought it's better idea to provide
>> additional protected abstract methods while retaining them as final.
> 

providing additional methods would be ok. Just having a (abstract) class
without any possibility to extend it will lead to problems at some
time/point, I think. Even if the normal way to change/encode/log messages is
a filter at the chain, there may be some special requirement to extend the
write method or any other method. I'm very careful with final statements,
because you don't know what other people will do with your classes (and
sometimes you don't want to know ;-) )



>> All I/O requests to AbstractIoSession will be forwarded to an
>> IoProcessor.  You can set the processor of the DummySession by calling
>> setProcessor() and you can override flush() there
> 

That's an idea. actually I don't know how to implement this, but maybe I get
it working.



>> However, it's very inconvenient to implement a dummy IoProcessor
>> comparing to just overriding write() method.  Let me rewrite
>> DummySession not extending AbstractIoSession for maximum flexibility.
> 

That would be nice :-)



> Alternatively, you could simply set your IoHandler to get notified
> when write() method is invoked?  Doesn't it make sense?
> 

I don't think so. My IoHandler is the tested class, and the test method
wants to know if the IoHandler writes out the correct messages and does
other things correctly. So the IoHandler shouldn't know that it's beeing
tested.

regards from Germany
Steve
-- 
View this message in context: http://www.nabble.com/final-AbstractIoSession-tf4889613s16868.html#a14125321
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: final AbstractIoSession

[Trustin Lee <tr...@gmail.com>]

Hi Steve,

On Dec 6, 2007 9:07 PM, Steve Ulrich (proemion)
<st...@proemion.com> wrote:
>
> Hi Trustin
>
>
> Trustin Lee wrote:
> >
> > I thought about this issue again and again every night (OK, I'm
> > exaggerating) and realized what you want to do (overriding
> > AbstractIoSession.write()) can be done alternatively by adding a
> > filter that intercepts the write call.  Does it fulfill your needs?
> >
> hmm... somehow.
> I did it this way now, but in my opinion it's not the best possible
> solution. As I wrote before, I'm working on a test class which is testing my
> handler class. As far as I understand the unit test sight of things, I
> should mock up nearly everything I give to the tested method. This way I can
> evaluate what the method is doing, without giving any attention to the
> environment. That's why I wanted to override/mock the write method. But I'm
> not interested in everything, ie. get/setAttributes.

Creating a mock object for IoFilterChain or IoSession is often a very
complicated task due to its complexity and because the mock
implementor has to implement most of the functionality just like the
real implementation.  That was why I provided full featured
DummySession with built in default IoFilterChain implementation.  It's
the heart of MINA so it seemed almost impossible to create a mock
filter chain or attribute map to me.  If someone could come up with
more elegant solution, I would be more than happy.

> > I also would like to emphasis again that making concrete methods final
> > in an abstract class is good for maintenance because it doesn't lead
> > the subclasses to weird behaviors at least.
>
> Maybe there are some points where final statements helps to understand
> things. Maybe my intention is not a usual thing and/or I misunderstood
> something. I just wanted to make sure, that this is well thought and point
> out some possible problems.
> There are no other people crying and you spend some nights over it now and
> have no doubt about that change, so I think that will be ok.

Thank you for your understanding and let's keep thinking about this
issue to roll out the better solution.

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: final AbstractIoSession

["Steve Ulrich (proemion)" <st...@proemion.com>]

Hi Trustin


Trustin Lee wrote:
> 
> I thought about this issue again and again every night (OK, I'm
> exaggerating) and realized what you want to do (overriding
> AbstractIoSession.write()) can be done alternatively by adding a
> filter that intercepts the write call.  Does it fulfill your needs?
> 
hmm... somehow.
I did it this way now, but in my opinion it's not the best possible
solution. As I wrote before, I'm working on a test class which is testing my
handler class. As far as I understand the unit test sight of things, I
should mock up nearly everything I give to the tested method. This way I can
evaluate what the method is doing, without giving any attention to the
environment. That's why I wanted to override/mock the write method. But I'm
not interested in everything, ie. get/setAttributes.



> I also would like to emphasis again that making concrete methods final
> in an abstract class is good for maintenance because it doesn't lead
> the subclasses to weird behaviors at least.
> 

Maybe there are some points where final statements helps to understand
things. Maybe my intention is not a usual thing and/or I misunderstood
something. I just wanted to make sure, that this is well thought and point
out some possible problems.
There are no other people crying and you spend some nights over it now and
have no doubt about that change, so I think that will be ok.

regards and thanks from Germany

Steve

-- 
View this message in context: http://www.nabble.com/final-AbstractIoSession-tf4889613s16868.html#a14191004
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: final AbstractIoSession

[Trustin Lee <tr...@gmail.com>]

Hi Steve,

I thought about this issue again and again every night (OK, I'm
exaggerating) and realized what you want to do (overriding
AbstractIoSession.write()) can be done alternatively by adding a
filter that intercepts the write call.  Does it fulfill your needs?

I also would like to emphasis again that making concrete methods final
in an abstract class is good for maintenance because it doesn't lead
the subclasses to weird behaviors at least.

Thanks,
Trustin

On Dec 3, 2007 5:18 PM, Steve Ulrich (proemion)
<st...@proemion.com> wrote:
>
> Hi
>
>
> Trustin Lee wrote:
> >
> > On Nov 29, 2007 10:18 AM, Trustin Lee <tr...@gmail.com> wrote:
> >> The reason I changed all the methods in AbstractIoSession to be final
> >> was because I didn't see much room for extension there.  If there's
> >> any need for extension, I thought it's better idea to provide
> >> additional protected abstract methods while retaining them as final.
> >
>
> providing additional methods would be ok. Just having a (abstract) class
> without any possibility to extend it will lead to problems at some
> time/point, I think. Even if the normal way to change/encode/log messages is
> a filter at the chain, there may be some special requirement to extend the
> write method or any other method. I'm very careful with final statements,
> because you don't know what other people will do with your classes (and
> sometimes you don't want to know ;-) )
>
>
>
> >> All I/O requests to AbstractIoSession will be forwarded to an
> >> IoProcessor.  You can set the processor of the DummySession by calling
> >> setProcessor() and you can override flush() there
> >
>
> That's an idea. actually I don't know how to implement this, but maybe I get
> it working.
>
>
>
> >> However, it's very inconvenient to implement a dummy IoProcessor
> >> comparing to just overriding write() method.  Let me rewrite
> >> DummySession not extending AbstractIoSession for maximum flexibility.
> >
>
> That would be nice :-)
>
>
>
> > Alternatively, you could simply set your IoHandler to get notified
> > when write() method is invoked?  Doesn't it make sense?
> >
>
> I don't think so. My IoHandler is the tested class, and the test method
> wants to know if the IoHandler writes out the correct messages and does
> other things correctly. So the IoHandler shouldn't know that it's beeing
> tested.
>
> regards from Germany
> Steve
> --
> View this message in context: http://www.nabble.com/final-AbstractIoSession-tf4889613s16868.html#a14125321
>
> Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
>
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6