Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke....) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the "final" qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException("message");
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : "Null messages are not allowed";
...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
