Re: Why only public methods on interfaces?
On 04/07/2011 08:09 PM, kramer31 wrote:
Could someone please explain to me the rational behind only allowing
public methods on interfaces? In my mind, protection and interfaces
are two independent if perhaps somewhat related concepts.
An interface is a public contract of methods that an object guarantees
it will support. In my view, the idea of an interface is that you are
letting someone else do the implementing. That "someone else" part
implies that the methods can't be package-protected, since it might not
be in your package. Private interface methods would of course be
useless, and protected methods would be severely limited to only the
implementing classes. In my mind, protected means "it's really private,
but you need to have your children see or use them", which suggests that
a protected method is inherently tied up in the implementation as
opposed to an interface.
For instance, I have an aspect which creates a proxy of a given
interface (which handles transaction propagation). Now in order to
use this aspect, I need an interface (otherwise, no proxy can be
created). However, I have some methods on this class which I would
like to proxy which are public, some are protected, some are package.
Because of this stupid restriction, I have to make all of the methods
public, or do ridiculous things with protection on inner classes.
You can use abstract classes where reasonable; where not reasonable, it
is also possible to make top-level package-private interfaces.
There are other examples, too. In fact one could imagine a case where
one would only want protected methods on an interface.
I would use an abstract class in that case. Think about stuff like an
AbstractDefaultImpl class, which implements most of the methods on top
of a simpler protected interface.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth