Why interface have only public member and methods

Question

This is very basic question of interview that can we declare a method as private inside interface and my answer is simple in interface we have only public variable or methods and then next question comes up... why ?

Answer 1

Interface has a semantic of a public contract provided by some implementation. It is like the API which class (or globally modules, subsystems, components, ...) privides to its clients. Private methods are used to handle some inner logic and thus depend on what actually implementation is. It is context-dependent. So, if class client needs to call private method, than 1) it must be public or 2) there is a bad design practice.

That's why as an abstraction interface can be considered as a fundamental basis of OOP, it is very important instrument for realization of the things like abstraction, encapsulation and polymorphism.

Answer 2

There are various interpretations of how interface members could have different visibilities. While there are probably more conceivable levels for visibility of identifiers, let us just have a look at those available in C#, with some thoughts of whether they could be meaningfully integrated into interfaces.

1) Interface members are only visible to code outside of the interface based on the rules of the respective visibility level.

• public: Interface members in C# are public by default, so this works.
• internal: If single interface members could be declared as internal, it would mean that a part of the interface could only be implemented by classes from the assembly that the interface resides in. A similar situation is already existing in cases where abstract class members or constructors of abstract classes are declared as internal - this effectively prevents subclassing outside of the assembly of the base class.
  As for scenarios where this might be used, think of APIs that return objects that later get consumed again by said API. If, for some reason, the API can only consume objects that it instantiated itself, being able to declare the base class in a way that 3rd party code cannot derive its custom classes, but only use what it gets from the API, while not being able to do the same with interfaces feels oddly asymmetrical.
• protected: Protected members are only visible from within their own class, and any of its subclasses. Applying the same assumptions as above, this would mean that only code within the interface declaration itself (well, an interface can contain almost no code where this could be relevant¹), of derived interfaces (same as before), and possibly of classes implementing the interface could see those protected members.
  The latter case is where things might become interesting, if only in rather contrived situations: A method within that class may want to consume anything that implements the interface, be it the current instance of the class itself, or any other type nested therein, while getting semi-exclusive access to the protected methods.
• private: Everything with private visibility is only visible to the declaring interface itself. As interface members can hardly¹ be referenced from within the interface itself, this would probably not be very useful. However, there may still be corner cases, such as const definitions within an interface that are referenced in attributes in said interface, but should not be available to outside code - however, C# does not allow for const values in interfaces, even though a similar feature is not unprecedented in the CLI world.

2) Interface members must be implemented with (at least?) the visiblity specified in the interface and adhere to that visibility when accessing the member via a reference typed to the class, but are generally publicly visible when accessing the member via a reference typed to the interface.

Again, there would be no change in the case of public members, while internal, protected and private visibility would allow for interfaces that allow for an apparently partial implementation. A similar effect can currently be achieved by explicit interface implementation, so in some respect, this would be syntactic sugar to avoid writing the same method twice, once with the intended visibility, and once with the interface-specific explicit implementation declaration (even if the latter often only forwards calls).

3) For the sake of completeness, even though your question didn't sound like including this option: For each class, the visibility of the whole interface is determined by the implementor.

Like this, a class could implement an interface, but that fact would only be apparent within the respective visibility level, while outside, the class would simply not be considered assignment-compatible or castable to that interface.
This may be particularly beneficial if the interface itself needs to have a lesser visibility than the class, as the interface should be processed only internally and is meaningless to the outside world. Currently, this is not possible in C#; interfaces need to be at least as accessible as their implementing classes. But then, this can also be achieved by implementing an internal interface in a public class.

---

As there are so many ways that visibility of interface members could be feasible and, at least in some cases, useful, the most definitive answer to this question is probably "because the development team decided to specify C# this way".

¹Presumeably, the nameof operator of C# 6 could be used on a protected/private interface member in an attribute declaration of the same interface.

Answer 3

Interfaces are contracts that classes require to implement in order to ensure that the consumer of some given class will receive instances of a class which mandatorily implements an interface.

If interfaces would allow private members, the fact that you couldn't invoke interface members which are hidden from the public surface would defeat the purpose of an interface, because a consumer wouldn't be able to call these private members (so... why it would use an interface?).

For example, interfaces provide typing to objects. If some consumer code relies on receiving objects implementing some interface to avoid redundant dependencies on the assembly which uses it and the whole assembly has access to an interface which doesn't provide members publicly, how that consumer would work with the so-called object?

public interface IDoesSomething
{
     private void Do();
} 

public void SomeMethod(IDoesSomething some) 
{
    some.????? // <---- what? the object doesn't have public members!
}

In fact, since interfaces are just metadata, I understand that you might think "I would declare private members to force implementers to call some logic in an expected order", but again, since they're just metadata, you've no way to ensure that some public member will call a private member in the right order. And implementations wouldn't have access to interface private members because they would need to be protected for that matter (that's why abstract classes exist)...

Answer 4

the Answer is too simple ;

When a class extend from an interface , members and methods o this interface should be accessible by this class , that's why theu have to be public