2018-05-31 19:52 GMT+02:00 Lyor Goldstein <[email protected]>:
> > >> 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.
Are you thinking about interfaces such as InitializingBean, DisposableBean,
etc.. ?
I think those are slightly different : they serve a very specific purpose
as they are interfaces
that can be optionally implemented by beans to provide a specific behavior.
The fact those all disposable beans now extend a single interface is a
consequence
not a goal : the goal is to be able to recognize and call the dispose
method.
In our case, I don't see any real purpose for all those interfaces beyond
linking together
unrelated objects just because they hold the same kind object.
> 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
>
--
------------------------
Guillaume Nodet
