C Interfaces Implicit implementation versus Explicit implementation

Question

What are the differences in implementing interfaces implicitly and explicitly in C    When should you use implicit and when should you use explicit   Are there any pros and or cons to one or the other     Microsoft s official guidelines  from first edition Framework Design Guidelines  states that using explicit implementations are not recommended  since it gives the code unexpected behaviour   I think this guideline is very valid in a pre-IoC-time  when you don t pass things around as interfaces   Could anyone touch on that aspect as well

User · Answer

One important use of explicit interface implementation is when in need to implement interfaces with mixed visibility.

The problem and solution are well explained in the article C# Internal Interface.

For example, if you want to protect leakage of objects between application layers, this technique allows you to specify different visibility of members that could cause the leakage.

User · Answer

In addition to excellent answers already provided  there are some cases where explicit implementation is REQUIRED for the compiler to be able to figure out what is required  Take a look at IEnumerable lt T gt  as a prime example that will likely come up fairly often   Here s an example   public abstract class StringList   IEnumerable lt string gt        private string    list   new string     foo    bar    baz                      region IEnumerable lt string gt  Members     public IEnumerator lt string gt  GetEnumerator                 foreach  string s in  list            yield return s               endregion       region IEnumerable Members     IEnumerator IEnumerable GetEnumerator                 return this GetEnumerator               endregion     Here  IEnumerable lt string gt  implements IEnumerable  hence we need to too  But hang on  both the generic and the normal version both implement functions with the same method signature  C  ignores return type for this   This is completely legal and fine  How does the compiler resolve which to use  It forces you to only have  at most  one implicit definition  then it can resolve whatever it needs to   ie   StringList sl   new StringList        uses the implicit definition  IEnumerator lt string gt  enumerableString   sl GetEnumerator       same as above  only a little more explicit  IEnumerator lt string gt  enumerableString2     IEnumerable lt string gt  sl  GetEnumerator       returns the same as above  but via the explicit definition IEnumerator enumerableStuff     IEnumerable sl  GetEnumerator      PS  The little piece of indirection in the explicit definition for IEnumerable works because inside the function the compiler knows that the actual type of the variable is a StringList  and that s how it resolves the function call  Nifty little fact for implementing some of the layers of abstraction some of the  NET core interfaces seem to have accumulated

User · Answer

Implicit is when you define your interface via a member on your class  Explicit is when you define methods within your class on the interface  I know that sounds confusing but here is what I mean  IList CopyTo would be implicitly implemented as   public void CopyTo Array array  int index        throw new NotImplementedException        and explicitly as   void ICollection CopyTo Array array  int index        throw new NotImplementedException        The difference is that implicit implementation allows you to access the interface through the class you created by casting the interface as that class and as the interface itself  Explicit implementation allows you to access the interface only by casting it as the interface itself   MyClass myClass   new MyClass       Declared as concrete class myclass CopyTo   invalid with explicit   IList myClass  CopyTo   valid with explicit    I use explicit primarily to keep the implementation clean  or when I need two implementations  Regardless  I rarely use it   I am sure there are more reasons to use not use explicit that others will post   See the next post in this thread for excellent reasoning behind each

User · Answer

To quote Jeffrey Richter from CLR via C   EIMI means Explicit Interface Method Implementation      It is critically important for you to   understand some ramifications that   exist when using EIMIs  And because of   these ramifications  you should try to   avoid EIMIs as much as possible    Fortunately  generic interfaces help   you avoid EIMIs quite a bit  But there   may still be times when you will need   to use them  such as implementing two   interface methods with the same name   and signature   Here are the big   problems with EIMIs          There is no documentation explaining how a type specifically   implements an EIMI method  and there   is no Microsoft Visual Studio   IntelliSense support    Value type instances are boxed when cast to an interface    An EIMI cannot be called by a derived type       If you use an interface reference ANY virtual chain can be explicitly replaced with EIMI on any derived class and when an object of such type is cast to the interface  your virtual chain is ignored and the explicit implementation is called  That s anything but polymorphism   EIMIs can also be used to hide non-strongly typed interface members from basic Framework Interfaces  implementations such as IEnumerable lt T  so your class doesn t expose a non strongly typed method directly  but is syntactical correct

User · Answer

An implicit interface implementation is where you have a method with the same signature of the interface   An explicit interface implementation is where you explicitly declare which interface the method belongs to   interface I1       void implicitExample       interface I2       void explicitExample        class C   I1  I2       void implicitExample                 Console WriteLine  I1 implicitExample                  void I2 explicitExample                 Console WriteLine  I2 explicitExample                MSDN  implicit and explicit interface implementations

User · Answer

The previous answers explain why implementing an interface explicitly in C  may be preferrable  for mostly formal reasons   However  there is one situation where explicit implementation is mandatory  In order to avoid leaking the encapsulation when the interface is non-public  but the implementing class is public      Given  internal interface I   void M          Then explicit implementation correctly observes encapsulation of I     Both   I CExplicit  M and CExplicit M are accessible only internally  public class CExplicit  I   void I M             However  implicit implementation breaks encapsulation of I  because      I CImplicit  M is only accessible internally  while CImplicit M is accessible publicly  public class CImplicit  I   public void M           The above leakage is unavoidable because  according to the C  specification   All interface members implicitly have public access   As a consequence  implicit implementations must also give public access  even if the interface itself is e g  internal   Implicit interface implementation in C  is a great convenience  In practice  many programmers use it all the time everywhere without further consideration  This leads to messy type surfaces at best and leaked encapsulation at worst  Other languages  such as F   don t even allow it

User · Answer

Every class member that implements an interface exports a declaration which is semantically similar to the way VB NET interface declarations are written  e g   Public Overridable Function Foo   As Integer Implements IFoo Foo   Although the name of the class member will often match that of the interface member  and the class member will often be public  neither of those things is required  One may also declare   Protected Overridable Function IFoo Foo   As Integer Implements IFoo Foo   In which case the class and its derivatives would be allowed to access a class member using the name IFoo Foo  but the outside world would only be able to access that particular member by casting to IFoo  Such an approach is often good in cases where an interface method will have specified behavior on all implementations  but useful behavior on only some  e g  the specified behavior for a read-only collection s IList lt T gt  Add method is to throw NotSupportedException    Unfortunately  the only proper way to implement the interface in C  is   int IFoo Foo     return IFoo Foo      protected virtual int IFoo Foo         real code goes here         Not as nice

User · Answer

If you implement explicitly  you will only be able to reference the interface members through a reference that is of the type of the interface  A reference that is the type of the implementing class will not expose those interface members   If your implementing class is not public  except for the method used to create the class  which could be a factory or IoC container   and except for the interface methods  of course   then I don t see any advantage to explicitly implementing interfaces   Otherwise  explicitly implementing interfaces makes sure that references to your concrete implementing class are not used  allowing you to change that implementation at a later time   Makes sure   I suppose  is the  advantage   A well-factored implementation can accomplish this without explicit implementation   The disadvantage  in my opinion  is that you will find yourself casting types to from the interface in the implementation code that does have access to non-public members   Like many things  the advantage is the disadvantage  and vice-versa   Explicitly implementing interfaces will ensure that your concrete class implementation code is not exposed

User · Answer

Reason  1 I tend to use explicit interface implementation when I want to discourage  quot programming to an implementation quot   Design Principles from Design Patterns   For example  in an MVP-based web application  public interface INavigator       void Redirect string url      public sealed class StandardNavigator   INavigator       void INavigator Redirect string url            Response Redirect url            Now another class  such as a presenter  is less likely to depend on the StandardNavigator implementation and more likely to depend on the INavigator interface  since the implementation would need to be cast to an interface to make use of the Redirect method   Reason  2 Another reason I might go with an explicit interface implementation would be to keep a class s  quot default quot  interface cleaner  For example  if I were developing an ASP NET server control  I might want two interfaces   The class s primary interface  which is used by web page developers  and A  quot hidden quot  interface used by the presenter that I develop to handle the control s logic  A simple example follows  It s a combo box control that lists customers  In this example  the web page developer isn t interested in populating the list  instead  they just want to be able to select a customer by GUID or to obtain the selected customer s GUID  A presenter would populate the box on the first page load  and this presenter is encapsulated by the control  public sealed class CustomerComboBox   ComboBox  ICustomerComboBox       private readonly CustomerComboBoxPresenter presenter       public CustomerComboBox             presenter   new CustomerComboBoxPresenter this              protected override void OnLoad             if   Page IsPostBack  presenter HandleFirstLoad                  Primary interface used by web page developers     public Guid ClientId           get   return new Guid SelectedItem Value             set   SelectedItem Value   value ToString                     quot Hidden quot  interface used by presenter     IEnumerable lt CustomerDto gt  ICustomerComboBox DataSource   set       The presenter populates the data source  and the web page developer never needs to be aware of its existence  But s It s Not a Silver Cannonball I wouldn t recommend always employing explicit interface implementations   Those are just two examples where they might be helpful

User · Answer

Implicit definition would be to just add the methods   properties  etc  demanded by the interface directly to the class as public methods   Explicit definition forces the members to be exposed only when you are working with the interface directly  and not the underlying implementation   This is preferred in most cases    By working directly with the interface  you are not acknowledging  and coupling your code to the underlying implementation  In the event that you already have  say  a public property Name in your code and you want to implement an interface that also has a Name property  doing it explicitly will keep the two separate  Even if they were doing the same thing I d still delegate the explicit call to the Name property  You never know  you may want to change how Name works for the normal class and how Name  the interface property works later on  If you implement an interface implicitly then your class now exposes new behaviours that might only be relevant to a client of the interface and it means you aren t keeping your classes succinct enough  my opinion

User · Answer

I use explicit interface implementation most of the time  Here are the main reasons   Refactoring is safer  When changing an interface  it s better if the compiler can check it  This is harder with implicit implementations   Two common cases come to mind    Adding a function to an interface  where an existing class that implements this interface already happens to have a method with the same signature as the new one  This can lead to unexpected behavior  and has bitten me hard several times  It s difficult to  see  when debugging because that function is likely not located with the other interface methods in the file  the self-documenting issue mentioned below   Removing a function from an interface  Implicitly implemented methods will be suddenly dead code  but explicitly implemented methods will get caught by compile error  Even if the dead code is good to keep around  I want to be forced to review it and promote it    It s unfortunate that C  doesn t have a keyword that forces us to mark a method as an implicit implementation  so the compiler could do the extra checks  Virtual methods don t have either of the above problems due to required use of  override  and  new    Note  for fixed or rarely-changing interfaces  typically from vendor API s   this is not a problem  For my own interfaces  though  I can t predict when how they will change   It s self-documenting  If I see  public bool Execute    in a class  it s going to take extra work to figure out that it s part of an interface  Somebody will probably have to comment it saying so  or put it in a group of other interface implementations  all under a region or grouping comment saying  implementation of ITask   Of course  that only works if the group header isn t offscreen    Whereas   bool ITask Execute    is clear and unambiguous   Clear separation of interface implementation  I think of interfaces as being more  public  than public methods because they are crafted to expose just a bit of the surface area of the concrete type  They reduce the type to a capability  a behavior  a set of traits  etc  And in the implementation  I think it s useful to keep this separation   As I am looking through a class s code  when I come across explicit interface implementations  my brain shifts into  code contract  mode  Often these implementations simply forward to other methods  but sometimes they will do extra state param checking  conversion of incoming parameters to better match internal requirements  or even translation for versioning purposes  i e  multiple generations of interfaces all punting down to common implementations     I realize that publics are also code contracts  but interfaces are much stronger  especially in an interface-driven codebase where direct use of concrete types is usually a sign of internal-only code    Related  Reason 2 above by Jon   And so on  Plus the advantages already mentioned in other answers here    When required  as per disambiguation or needing an internal interface Discourages  programming to an implementation   Reason 1 by Jon    Problems  It s not all fun and happiness  There are some cases where I stick with implicits    Value types  because that will require boxing and lower perf  This isn t a strict rule  and depends on the interface and how it s intended to be used  IComparable  Implicit  IFormattable  Probably explicit  Trivial system interfaces that have methods that are frequently called directly  like IDisposable Dispose     Also  it can be a pain to do the casting when you do in fact have the concrete type and want to call an explicit interface method  I deal with this in one of two ways    Add publics and have the interface methods forward to them for the implementation  Typically happens with simpler interfaces when working internally   My preferred method  Add a public IMyInterface I   get   return this       which should get inlined  and call foo I InterfaceMethod    If multiple interfaces that need this ability  expand the name beyond I  in my experience it s rare that I have this need

User · Answer

In addition to the other reasons already stated  this is the situation in which a class is implementing two different interfaces that have a property method with the same name and signature        lt summary gt      This is a Book      lt  summary gt  interface IBook       string Title   get        string ISBN   get            lt summary gt      This is a Person      lt  summary gt  interface IPerson       string Title   get        string Forename   get        string Surname   get            lt summary gt      This is some freaky book-person       lt  summary gt  class Class1   IBook  IPerson            lt summary gt          This method is shared by both Book and Person          lt  summary gt      public string Title               get                       string personTitle    Mr               string bookTitle    The Hitchhikers Guide to the Galaxy                   What do we do here              return null                        region IPerson Members      public string Forename               get   return  Lee                public string Surname               get   return  Oades                 endregion       region IBook Members      public string ISBN               get   return  1-904048-46-3                 endregion     This code compiles and runs OK  but the Title property is shared   Clearly  we d want the value of Title returned to depend on whether we were treating Class1 as a Book or a Person  This is when we can use the explicit interface   string IBook Title       get               return  The Hitchhikers Guide to the Galaxy            string IPerson Title       get               return  Mr            public string Title       get   return  Still shared         Notice that the explicit interface definitions are inferred to be Public - and hence you can t declare them to be public  or otherwise  explicitly   Note also that you can still have a  shared  version  as shown above   but whilst this is possible  the existence of such a property is questionable  Perhaps it could be used as a default implementation of Title - so that existing code would not have to be modified to cast Class1 to IBook or IPerson   If you do not define the  shared   implicit  Title  consumers of Class1 must explicitly cast instances of Class1 to IBook or IPerson first - otherwise the code will not compile

[c#] C# Interfaces. Implicit implementation versus Explicit implementation

Examples related to c#

Examples related to .net

Examples related to interface