In an interview a while ago for a .NET position the interviewer asked me "what would you use a private interface for?".
I asked him did he mean the difference between implicit vs explicit interface implementation to which he answered no.
So I'm wondering:
Public-Private Interface (PPI) is understood to exist where the public sector provides a legal, regulatory or contractual benefit, subsidy or concession to private sector entities with the intent of achieving sustainable development outcomes, human rights impact or other public objectives.
Private methods can be implemented static or non-static. This means that in an interface we are able to create private methods to encapsulate code from both default and static public method signatures. bar() is able to make use of the private method baz() by calling it from it's default method.
As of Java 9, methods in an interface can be private. A private method can be static or an instance method, but it cannot be a default method since that can be overridden.
An interface could be private within another class
public class MyClass { private interface IFoo { int MyProp { get; } } private class Foo : IFoo { public int MyProp { get; set; } } public static void Main(string[] args) { IFoo foo = new Foo(); return foo.MyProp; } }
in terms of utility it simply hides from other code, even within the same assembly, that said interface exists. The utility of this is not terribly high in my opinion.
Explicit interface implementation is a different matter, has some very useful cases (especially when working with generics and older non generic interfaces) but I would not term it 'private interfaces' and would not say that the term is commonly used in that manner.
Using the two techniques together you can do:
public class MyClass { private interface IFoo { int MyProp { get; } } public class Foo : IFoo { int IFoo.MyProp { get; set; } } public static void Main(string[] args) { IFoo foo = new Foo(); return foo.MyProp; } } public class HiddenFromMe { public static void Main(string[] args) { MyClass.Foo foo = new MyClass.Foo(); return foo.MyProp; // fails to compile } }
This allows you to expose the nested classes in some fashion while allowing the parent class to invoke methods on them that the outside world cannot. This is a potentially useful case but is not something I would wish to use very often. Certainly it's use in an interview smacks of being a boundary case the interviewer is using because they've seen it and though it was 'interesting'
From this link.
Private Interface Inheritance
Historically, languages have permitted private inheritance. In C++, you can inherit from a type without being polymorphically compatible with that type. It’s just a convenient way to reuse an implementation. In the CTS, you cannot do private implementation inheritance. But you can use private interface inheritance.
Private interface inheritance is really just a way to hide methods from a type’s public API. They are compiled into private methods but are actually accessible through a type’s interface map. In other words, they can only be called through a reference typed as the interface on which the method is defined. An example will make this easier to understand:
class PrivateImplementer : IFoo { void IFoo.Foo() { Console.WriteLine("PrivateImplementer::IFoo.Foo"); } }
In this case,
PrivateImplementer
is publicly known to implementIFoo
. Thus, an instance can be treated polymorphically as an instance ofIFoo
. But you cannot actually call Foo on it unless you do treat it as anIFoo
. This code demonstrates this:PrivateImplementer p = new PrivateImplementer(); p.Foo(); // This line will fail to compile IFoo f = p; f.Foo();
You can select individual methods of an interface to implement privately. For instance, if
PrivateImplementer
implementedIFooBar
, it might choose to implement Foo privately, but Bar publicly using the ordinary syntax.In practice, there aren’t many common cases where you would use private implementation. The
System.Collections.Generic
library uses this approach to secretly implement all of the legacy System.Collections weakly typed interfaces. This makes backwards compatibility "just work," for example passing an instance ofList<T>
to a method that expects anIList
will work just fine. In this specific example, cluttering the new type APIs would have been a pity (there are quite a few methods necessary for the weakly typed interoperability).
"No," is a pretty poor answer if he was looking to find out what you knew. Sounds like someone who just wants to show how much they know.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With