39

When I implement an interface method, I am forced to make it a public method.

We may have cases where we want to use either the default (like in case of access within the same package) or protected.

Can anyone please explain the reason behind this limitation?

nbro
  • 15,395
  • 32
  • 113
  • 196
Vishnu
  • 446
  • 1
  • 7
  • 10

5 Answers5

59

Interfaces are meant to define the public API of a type - and only that, not its implementation. So any method (or static member) you define in an interface is by definition public.

Since an interface can't contain any concrete implementation, there is no way to call any member methods from within. And declaring such methods but leaving the calls to them to subclasses or totally unrelated clients would mean your type definition is incomplete and brittle. That is why if you need to define protected or package access members, you can do so in an abstract class (which may also contain implementation).

Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • 11
    I think this answer is right, but it's basically a roundabout way of saying, "because that's what the Java folks wanted." You could come up with perfectly reasonable arguments for having protected methods, too (package-private might be a bit harder to justify). But you certainly can't have private methods, since those are never inherited. My guess is that, rather than saying "this subset of visibilities, and here's why this-but-not-that," they thought it'd be simpler to just say "here's the one visibility you get." – yshavit Mar 08 '12 at 08:45
  • @yshavit, I tried to think about *why* the Java folks wanted things to be like this. One piece of information that was left out above is that they added interfaces to the language specifically because they wanted to disallow multiple inheritance, and all the problems it brought forth in C++. – Péter Török Mar 08 '12 at 08:52
  • 1
    @yshavit, would be interested in any "perfectly reasonable arguments for having protected methods" though :-) – Péter Török Mar 08 '12 at 08:53
  • +1 for illustrating the conceptual difference between interfaces and abstract classes. – pap Mar 08 '12 at 08:56
  • Technically, the methods are *public* anyway -- you can always get a reference to the interface if you have the object reference. – Simon Richter Mar 08 '12 at 09:58
  • well thats just language dependent. in C# interfaces are always public. – Nahum Mar 08 '12 at 10:07
  • @PéterTörök Just off the top of my head, I could imagine an interface that can gather and report information of some sort, but which also has callback methods with specific promises on the caller's side (e.g. that they all be called on some specific thread). It'd be nice if you could mark those protected so that only the package which defines the interface can get at them (plus the class itself, of course). Or possibly you don't want people to be able to `getFoo()` directly, but only through a method (defined somewhere in that package) which wraps it in some `Bar` before returning it. Etc. – yshavit Mar 08 '12 at 14:14
  • @yshavit, IMHO all this can be easily solved using two separate interfaces, one of which is package private. – Péter Török May 14 '12 at 14:00
  • @PéterTörök Even if you did that, the concrete class that implements the interface would have to have those methods be public. So the methods would still be part of the public API, just not organized as part of the package-private interface... almost the worst of both worlds, since you have to publish this conceptually-hidden method, but not the context in which it's defined. – yshavit May 14 '12 at 17:02
  • @yshavit, only if you [program for concrete classes, not interfaces](http://stackoverflow.com/questions/2697783/what-does-program-to-interfaces-not-implementations-mean). Otherwise, you publish an instance of PublicInterface to some client (possibly in another package) and an instance of PackagePrivateInterface to some other client (within the same package). Noone cares about whether or not these are the same physical object. – Péter Török May 15 '12 at 07:25
  • "And declaring such methods but leaving the calls to them to subclasses or totally unrelated clients would mean your type definition is incomplete and brittle. " - Can you elaborate how letting unrelated clients access such a method leaves the type incomplete? @PéterTörök – sindhu_sp May 28 '20 at 20:34
  • In Java The public access specifier indicates that the interface can be used by any class in any package. If you do not specify that the interface is public, then your interface is accessible only to classes defined in the same package as the interface. – O_K Jun 16 '20 at 07:21
12

Maybe this will provide some answers.

To my knowledge, you use interfaces to allow people from outside your code to interact with your code. To do this, you need to define your methods public.

If you would like to force someone to override a given set of private methods, you might want to declare an abstract class with a series of abstract protected methods.

nbro
  • 15,395
  • 32
  • 113
  • 196
npinti
  • 51,780
  • 5
  • 72
  • 96
  • 4
    "abstract private methods"... did you mean "abstract protected methods"? – BoltClock Mar 08 '12 at 08:34
  • @npinti-well put in simplest terms! – Vishnu Mar 08 '12 at 08:40
  • Or abstract default (package) scope methods – Amir Pashazadeh Mar 08 '12 at 08:46
  • 2
    However, Joshua Bloch strongly encourages us to use interfaces as -types- and to use those types to refer to objects. It's a nice idea, but it develops two ways to conceptualize interfaces: as a mechanism for using user-defined types in a way that doesn't interfere will single-inheritance; and as an API contract. Since we have these two, I agree that it would be VERY nice if we did not have to make interface methods public in order to keep those UDT's that we did not want to export encapsulated. – scottb Jun 09 '13 at 01:01
1

An interface is a contract that the class that implements it will have the methods in the interface. The interface is used to show the rest of the program that this class has the methods and that they could be called

WhiteKnight
  • 4,938
  • 5
  • 37
  • 41
nist
  • 1,706
  • 3
  • 16
  • 24
  • Yes, but interfaces are also types. Sometimes, programmers want to use types that they've created without exporting them as part of the API. This is where forcing interface methods to be public is annoying. – scottb Jun 09 '13 at 01:03
0

EDIT: This answer is meant for C# interface implementations. In this case of Java the scenario is similar just that the syntactic analyzer wants a public keyword mentioned in the interface, which is implicitly done in C#

Interface methods are implicitly public in C# because an interface is a contract meant to be used by other classes. In addition, you must declare these methods to be public, and not static, when you implement the interface. 

interface IStorable
{
     void Read( );
     void Write(object obj);
}

Notice that the IStorable method declarations for Read( ) and Write( ) do not include access modifiers (public, protected ..). In fact, providing an access modifier generates a compile error. 

class Document : IStorable
{
     public void Read( )
     {
         //
     }
     public void Write(object obj)
     {
         //
     }
}

Just think about interfaces as Contracts to be implemented as public

Jerric Lyns John
  • 936
  • 10
  • 25
-1

  1. If we mark a interface method as private the implementing class wont see the method and cant override it.

  2. If we mark a interface method as protected the implementing class wont see the method unless it is in the same package as the interface.

  3. If we mark a interface method without any access modifier the
    implementing class wont see the method unless it is in the same
    package as the interface

user1929905
  • 389
  • 3
  • 9
  • 25