C# 8.0 Expected Features Part – II : Implementation of method in the Interface

C8

In my previous post, I have explained about one of the first four features of C# 8.0 which has been announced by Microsoft recently.

In this post, I will explain one more future feature which is Default Interface Methods.

This feature will allow interfaces to fully define methods just like abstract classes. However,  interfaces will still not be able to declare constructors or fields.

Let us see what it is:

Let us take one example of an interface, like IMessage and it has one method named Message as shown below:

interface IMessage {
   void Message();
}

And a class will implement it as below:

Class Test : IMessage
{
}

Now imagine we want to add a new method to the interface, it will result in lots of errors in all the classes which have inherited IMessage interface.

Here comes the new feature which changes some basic functionalities of C# language.

We will create a method with the implementation in the interface. Yes, you read it right, we will be able to write the implementation of the method into the interface as below:

interface IMessage {
    void Message();

    void MessageAll(IEnumberable<MyClass> myClass){ 
       foreach(var i in myClass)
       {
              //// Your code
       }
   }
}

So no need to write newly added method into all the classes which inherit IMessage interface.

It is cool, isn’t it?

One basic question would come in the mind is, what is the difference between this and the abstract class?

They are bit similar but there are some major differences.

One of the difference is:

  • The interface can be used for multiple inheritances but Abstract class can not be used
  • Interfaces will still not be able to declare constructors or fields.

Some useful points for Default Methods feature:

  • “Full abstraction” where we used to have plain interfaces and all classes were forced to have its own implementation. Now we are polluting classes with some default implementation for methods which they don’t even know those exist.
  • It also breaks interface segregation principle, if we have to change an interface in future and it should not break all the classes but some of the classes need to have the new method added means, the interface is not granular enough and it’s time to introduce new interface and implement for the required classes.

Java announced almost similar feature with 8.0 version earlier and it is becoming so famous among Java developers and it will soon become famous between .Net developers as well 🙂

 

Advertisements

6 thoughts on “C# 8.0 Expected Features Part – II : Implementation of method in the Interface

    1. Hey, you can find your answer from this thread by rolfbjarne: https://github.com/dotnet/csharplang/issues/52

      Extension methods break polymorphism, I can’t see how you’d implement the following using extension methods:

      interface I {
      public int GetSomething () { return 0; }
      }
      class A : I { }
      class B : I {
      public int GetSomething () { return 1; }
      }
      class C : I {
      public int GetSomething () { return 2; }
      }
      class Other {
      static void PrintSomething (I obj) {
      Console.WriteLine (obj.GetSomething ());
      }
      static void Main () {
      PrintSomething (new A ()); // this should print 0
      PrintSomething (new B ()); // this should print 1
      PrintSomething (new C ()); // this should print 2
      }
      }

      Like

  1. How do you solve the multiple inheritance problems? Interface A implements MethodA and interfaceB also implement methodA(). If class C inherits both InterfaceA and InterfaceB then what will happen? Which implementation will be called when you call methodA from methodC of Class c? One more thought is if this problem is solved by what ever means, then allowing multiple inheritance in class would be a better idea then this. This seems to be just trying to copy JAVA

    Like

  2. This seems like a bad idea. No, let me change that. This IS a bad idea. No, let me change that. This is a HORRIBLE idea.

    This blurs the line between interfaces and abstract classes for no good reason.

    Interfaces are quite clearly, and usefully, purposed to define a contract, not to implement the contract.

    If you need a base or default implementation, you should be using an abstract class for this.

    And now you’ve got multiple inheritance problems as described above, except they’re even worse. You don’t have to just worry about the same method being implemented in two interfaces, but potentially in an abstract class and an interface. You’ll need explicit calls and explicit definitions to make sure you’re getting the one you want, which means the caller now has to know far too much about what it’s calling.

    I fail to see how this satisfies a need that couldn’t already be satisfied in another, better way, such as the Adapter pattern.

    Please explain to me why anyone would want this, and why I shouldn’t laugh out loud if I see this code in a code review session and reject it automatically.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s