mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lyor Goldstein <lgoldst...@apache.org>
Subject Re: [DISCUSS] Some SSHD refactoring before 2.0.0
Date Thu, 31 May 2018 17:52:05 GMT
 > >>  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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message