> >> remove a few interfaces which are not actually used, i.e. they've
been
> introduced because various classes have methods with similar signatures,
> but there's no real concept behind
>
> I disagree with the characterization that they do not have a "real concept
> behind them" they represent contracts of entities that have similar
> attributes. IMO, all the various *XxxHolder*(s) represent an entity that
> provides whatever these "attribute" interfaces hold.
>>> Well, I would agree on this principle in theory.
However, I've seen no evidence throughout the code that this is actually
useful.
Perhaps I am influenced by years of dealing with *Spring* framework, but I
find reasoning about "narrow"
interfaces very useful - especially when mocking or proxying. I agree that
I cannot give an immediate example, but I found out that the in the long run
it yields benefits. Call it a gut feeling or a natural tendency - but
unless these marker interfaces cause harm (e.g. confusion, abuse) I would
prefer not to remove them - unless you very strongly feel otherwise.
>>> The isOpen() is mostly useless because close() is defined as being
indempotent. So the call to if (xx.isOpen()) { xx.close() } is simply less
readable for no gain.
>>> I disagree. I think we should not overextend the meaning of the
Channel
interface.If you look in the JVM, things like Socket, ZipFile, or even
InputStream
and OutputStreamdo not implement Channel.
>>> This also can lead to confusion with our SSHD related Channel interface
which is much a more important citizen in our code base.
I do not agree 100% with the claims or the examples (and I wish I could
take more time to discuss my reservations), but I don't feel as strongly
about this (as I do about the marker interfaces). I can easily live with
removing the *java.nio.channels.Channel* implementation unless a "real"
channel (...whatever it may mean) especially since I can see your point
that " This also can lead to confusion with our SSHD related Channel
interface"
Lyor
