Re: Interface Delegation or ??
My suspicion is that Lew and I are at the point where we're talking
past each other so I'll leave it here.
However in closing I would like to correct the idea I put forward that
there would not be a 'legitimate' use for code like:
package pack;
interface HiddenInterface {...}
public class SomeClass {
public void someMethod(HiddenInterface x) {...}
}
I'd suggested that this was legal but couldn't see any reason for it,
while Lew noted that NetBeans cautions against it and also suggested
that it wasn't a good idea. Despite our agreement, I now suspect we
were both wrong. Such a usage might be perfectly appropriate if we add
some additional interfaces to the package, e.g.,
final public interface Visible1 extends HiddenInterface {...}
final public interface Visible2 extends HiddenInterface {...}
Then for example we might have:
package otherpack;
public class AnotherClass implements Visible1 {
...
pack.SomeClass xxx = ...
xxx.someMethod(this);
...
}
Restricting the base interface to package visibility means that all of
the public interfaces must be declared in the pack package (assuming
we make all the derived interfaces final). So that package still can
limit the valid interfaces. We need to use the base interface in the
method signature to assure that we can handle all of the sub-
interfaces.
I could imagine something like this being needed in sophisticated
factory patterns though I've never had requirements for such - I very
rarely extend interfaces at all. It seems reasonably straightforward
but I've not explicitly checked that it's legal. Since NetBeans looks
at the entire project I'd expect it to notice the additional
interfaces and give up it's warning, but again I haven't checked.
While this is another reason one might use package interfaces, it does
not materially affect my earlier discussion of the extent to which
package level interfaces and their contents are visible to the public.
Merry Christmas to all!
Tom McGlynn