Why do interface methods have to be public




















I always added public abstract before, despite the style police, cause it made things clear and reminded the reader. Now I am vindicated because Java 8 and 9 complicate things user Isn't the lack of a block statement implication enough? Would you declare extends Object albeit it's implied? If the developer does not understand the redundancy, chances are they might not fully understand the concept behind the language feature , which is an even bigger problem than being confused about modifiers.

The developer must understand that the purpose of an interface is to create a contract that defines how a client can interact with an object. This suggests any method in an interface used for object interaction should be exposed to clients. If you declare a method private, you are explicitly stating that method is not meant to be called by clients, which in the case of interfaces is something that can't easily be inferred. Sign up to join this community. The best answers are voted up and rise to the top.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Now that not all method declarations in a Java Interface are public abstract, should the methods be declared with these modifiers? Ask Question. Asked 5 years, 3 months ago. Active 4 years, 9 months ago. Viewed 2k times. Improve this question. Community Bot 1. David Campbell David Campbell 3 3 bronze badges. Same section as in old accepted answer at SO suggests that introduction of default methods didn't change prior recommendation which was based on the same redundancy considerations: "An interface method lacking a default modifier or a static modifier is implicitly abstract It is permitted, but discouraged as a matter of style, to redundantly specify the abstract modifier for such a method declaration.

I thought things might change because the condition for a method to be implicitly abstract are becoming increasingly convoluted. In Java 9, that same sentence might be, "An interface method lacking a default modifier or a static modifier or a private modifier is implicitly abstract TBH I don't understand the reasoning behind "default" methods, and even static methods reach outside the scope of what interfaces are normally intended to do. Interfaces aren't supposed to be saddled with concretion.

That's why they're useful types for references. TrixieWolf default methods allow interfaces to evolve. Previously, and unlike classes, adding a method would break every implementation; now, you can grow an interface as long as you have a good candidate default.

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.

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.

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.

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.

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. Just think about interfaces as Contracts to be implemented as public. If we mark a interface method as private the implementing class wont see the method and cant override it.

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. 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. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. The CLR feature does much more than just that e. Perhaps it should be called something like "concrete methods in interfaces", or "traits"? This proposal requires a coordinated update to the CLR specification to support concrete methods in interfaces and method resolution. It is therefore fairly "expensive" and it may be worth doing in combination with other features that we also anticipate would require CLR changes.

My notes for showed that we decided not to allow this. However, there are at least two use cases for it:. Unfortunately this code cannot be refactored as a set of interfaces traits unless this is permitted. By the Jared principle of greed , it should be permitted. Closed issue: Should reabstraction be permitted? The LDM notes say that reabstraction is permitted in an interface. Not in a class. We decided to allow modifiers explicitly stated on interface members, unless there is a reason to disallow some of them.

This brings an interesting question around virtual modifier. Should it be required on members with default implementation? Alternatively, we could say that virtual modifier is required for a virtual member. This approach might provide better experience when a method is moved from a class to an interface:. Closed Issue: Should a concrete method with implementation be implicitly virtual? We understand that the implementation of I1. What if the assembly containing I2 is changed as follows and recompiled.

What happens when the program is run? An invocation of C as I1. Decision: Made Runs I2. M , which is the unambiguously most specific override at runtime. This "partial" implementation of the event is not permitted because, as in a class, the syntax for an event declaration does not permit only one accessor; both or neither must be provided. You could accomplish the same thing by permitting the abstract remove accessor in the syntax to be implicitly abstract by the absence of a body:.

Note that this is a new proposed syntax. In the current grammar, event accessors have a mandatory body. Closed Issue: Can an event accessor be implicitly abstract by the omission of a body, similarly to the way that methods in interfaces and property accessors are implicitly abstract by the omission of a body? Decision: No, event declarations require both concrete accessors or neither. Closed Issue: We should confirm that this is permitted otherwise adding a default implementation would be a breaking change :.

Decision: Yes, adding a body to an interface member declaration shouldn't break C. The previous question implicitly assumes that the sealed modifier can be applied to an override in an interface. This contradicts the draft specification. Do we want to permit sealing an override?

Source and binary compatibility effects of sealing should be considered. Decision: Let's not allowed sealed on overrides in interfaces. The only use of sealed on interface members is to make them non-virtual in their initial declaration.

The draft of the proposal prefers class overrides to interface overrides in diamond inheritance scenarios:. We require that every interface and class have a most specific override for every interface method among the overrides appearing in the type or its direct and indirect interfaces.

If there is no override, the method itself is considered the most specific override. Closed Issue: Confirm the draft spec, above, for most specific override as it applies to mixed classes and interfaces a class takes priority over an interface.

Boxing in this way defeats the principal benefits of a struct type. Moreover, any mutation methods will have no apparent effect, because they are operating on a boxed copy of the struct:. Decision: Not worry about it and just leave it as a wart. The draft spec suggests a syntax for base interface invocations inspired by Java: Interface. We need to select a syntax, at least for the initial prototype. Decision: The syntax is base Interface. The interface so named must be a base interface, but does not need to be a direct base interface.

Open Issue: Should base interface invocations be permitted in class members? In an interface, non-public members from base interfaces are overridden using the override modifier. If it is an "explicit" override that names the interface containing the member, the access modifier is omitted. Closed Issue: If it is an "implicit" override that does not name the interface, does the access modifier have to match?

Decision: Only public members may be implicitly overridden, and the access must match. Open Issue: Is the access modifier required, optional, or omitted on an explicit override such as override void IB. Open Issue: Is override required, optional, or omitted on an explicit override such as void IB. How does one implement a non-public interface member in a class? Perhaps it must be done explicitly? Closed Issue: How does one implement a non-public interface member in a class?

Decision: You can only implement non-public interface members explicitly. Decision : No override keyword permitted on interface members. What if the assembly containing I3 is changed as follows and recompiled. Decision : Throw an exception 5. Given that interfaces may be used in ways analogous to the way abstract classes are used, it may be useful to declare them partial.

This would be particularly useful in the face of generators. Proposal: Remove the language restriction that interfaces and members of interfaces may not be declared partial.

Open Issue: Is a static Main method in an interface a candidate to be the program's entry point? Can we please confirm or reverse our decision to permit non-virtual public methods in an interface?

Semi-Closed Issue: We think it is going to be useful, but will come back to it. This is a mental model tripping block. Open Issue: Does an override declaration in an interface introduce a new member? In a class, an overriding method is "visible" in some senses. For example, the names of its parameters take precedence over the names of parameters in the overridden method. It may be possible to duplicate that behavior in interfaces, as there is always a most specific override.

But do we want to duplicate that behavior? We say that private members are not virtual, and the combination of virtual and private is disallowed. But what about a property with a private accessor? Is this allowed? Is the set accessor here virtual or not? Can it be overridden where it is accessible? Does the following implicitly implement only the get accessor?

Is the following presumably an error because IA. Decision : The first example looks valid, while the last does not.

This is resolved analogously to how it already works in C. Our previous "resolution" to how to handle base invocations doesn't actually provide sufficient expressiveness.

It turns out that in C and the CLR, unlike Java, you need to specify both the interface containing the method declaration and the location of the implementation you want to invoke.

I propose the following syntax for base calls in interfaces. Decision : Decided on base N. M s , conceding that if we have an invocation binding there may be problem here later on.



0コメント

  • 1000 / 1000