Re: Interface Delegation or ??
tam@milkyway.gsfc.nasa.gov wrote:
Hmmm... I don't think I consider the visibility of a method part of
its implementation -- any more than say its return type.
Interfaces don't have implementation.
Regardless, I don't think the visibility of the interface makes much
practical difference if the interface is only implemented in package
level code.
It makes a difference to the visibility of the interface type, which is the
reason one mucks with visibility.
E.g., let's consider that we've adopted your rule and package visible
interfaces are implemented only in package visible classes. Clearly
the interface is not visible to the public, nor can any implementation
of any method in the interface be accessed outside the package.
So far, so good.
Now let's make the interface public. We still want to restrict use
the interface to one package, but we're exploring what making it
public does. So what happens?
There's your problem right there. If you want to restrict use of the
interface to just the package, why are you making it public? That makes no sense.
The clearest change is that external(to the package) users can now
access the constants defined in the interface. That's a real change
You should never define constants in an interface. That antipattern is an
Item in Joshua Bloch's /Effective Java/. Interfaces are there to define
contract, not implementation. Putting constants in an interface is an abuse.
and its certainly useful to restrict visibility of constants in some
cases, but our dicussion heretofore has focussed on how methods are
affected. What happens there?
Public users still cannot directly access the implementation of any of
the methods, because the class protections for each of the
implementing classes are still set to package level.
Because these classes, *by design*, are not intended for public use.
Ah, but they can now create their own implementation of the interface
and pass it in to some public method that takes the interface as an
input and thus get access to something they weren't able to get to
before... I.e.,
No previous implementation of the interface can have been passed to a public
method in a public class, since none of the type or its subtypes were publicly
visible. Your scenario cannot happen.
package pack;
public class SomeClass {
public void someMethod(HiddenInterface x) {...}
}
When the 'HiddenInterface' had package-private access, and was not in package
'pack', this method would have raised a compiler error.
...
package otherpack;
public class NewClass implements HiddenInterface {
void crackingMethod() {
someMethod(this);
}
}
where HiddenInterface is the interface that we just made public.
Here crackingMethod is able to inject an instance of the new user
class and clearly might have access where it didn't before. So this
seems new...
To what? Access to what? All the previous classes had package-private
access. Calling the method 'crackingMethod()' doesn't make it magically able
to crack anything.
Furthermore, why was the interface promoted to public access? Surely such a
decision is weighed against the cost of changes. But worrying about cracking
into a package-private implementation isn't one of them. In fact, it's one of
the most common idioms in Java to have package-private or private
implementations of public interfaces. What you tout as a disadvantage is
actually one of the great strengths of the language.
That's right, but why was there a public method in a public class that
used a type that didn't wasn't supposed to be available to the
public? The only legitimate reason I might see is that 'someMethod'
is itself defined in an interface so it needed to be public. But if
it's in an interface that uses HiddenInterface, then presumably this
second interface is also only supposed to be used within the package
so by hypothesis we shouldn't be implementing it in a public class.
Nor could any public method of a public class from a different package make
use of a non-public interface.
So what did the package level protection get us: It hid constants and
Constants that should never be defined in an interface in the first place.
it's probably useful as a bit of documentation: it can indicate we
should limit visibility of certain classes and methods, but at best it
should act as kind of backup, cleaning up if we make errors in some of
our visibility specifications for methods in public classes.
It isn't "documentation", it's a fundamental decision about the use of a type
whether to make it public or package-private.
That said, I'm not sure I agree with your first statement above...
Users should feel free to implement package level interfaces in public
No, they shouldn't. If it's in a different package, you get a compiler error.
The reason to make something package-private is to restrict its visibility.
If you don't restrict the visibility, then you have no reason to declare it
with restricted visibility. Your suggestion contradicts the very point of
declaring restricted visibility.
classes. There may be many cases where that's fine. All I've ever
said is that if they do so, they need to recognize that the
implementation of the methods of the interface must be visible to the
public regardless of the visibility of the interface itself.
Programmers need to be aware of the implications of the visibility rules in
their chosen language, yes. If you choose to implement a package-private
interface in a public class, that's fine, but users of the public class will
not have access to the supertype. To them, the methods will just look like
regular, non-contracted methods, just as if there were no interface involved.
Indeed, one must presume that is intentional, else why do such a thing?
I can see reasonable cases for any combination of public and package
classes implementing public and package interfaces, but the
interactions of the visibilities of the classes, interfaces and
methods are rather subtle.
The actual interactions are precisely specified for Java.
And all this is before we consider how inheritance might affect all of
this!
Interfaces exist for the whole purpose of inheritance. This is not "before we
consider" inheritance; in fact, my advice all along in this and the other
thread was based on the notion of inheritance. It's fundamental to the entire
conversation so far. It is the entire point. It is the heart of the matter,
and has been from the start. Not only are we not "before" such consideration,
we are steeped in it, drowning in it. It is the only thing under consideration.
Not dealing with the notion of inheritance in talking of package-private
visibility for interfaces and abstract classes (see upthread) invalidates any
possibility of understanding the issues involved, since the issues involved
*are inheritance issues*.
From the start, intrinsically.
--
Lew