Hi all,

                 While implementing an interface we need to implement all the methods of an interface otherwise the class becomes an abstract class .

What if there is an interface containing 30 methods but we do not require all the methods to be implemented, then in this case what should we do to prevent the class from being Abstract?

 

You have to implement them, even if only to throw a NotImplementedException.

(An interface with 30 member is a strong sign of a poorly factored design.)

You have to implement all methods, properties and events defined in the interface, otherwise you will get a compilation error.

 you might leave the body blank or throw a notimplemente exception, only be careful that if the method returns a value you must return something (for example, if the method returns a boolean value, you have to add return false or return true.

Not implementing methods of an interface in a class does not make it an abstract class. To make a class abstract you have to declare it as it explicitly.

 It has nothing to do with the interface although of course you can implement some interface method in an abstract class and then the classes inheriting it won't need to, but if  you implement a method you don't need as abstract, you still will have to implement it in child classes.

 I would say, if you don't need some methods, why don't you remove them from the interface?

As somebody say, 30 methods in an interface probably signs design problems although not necessarily, it kind of defeats the purpose of the interface, you might consider splitting them in multiple interfaces depending on the purposes of them. One of the purposes of an interface is to only expose the methods, properties and events that you need for a particular application (or part of it) without worrying about the implementation, if the interface declares too many members and it has to be implemented in multiple classes it will add a lot overhead, if it only needs to be implemente in one class, you might reconsider the need for it.

spillbean:

we need to implement all the methods of an interface otherwise the class becomes an abstract class

 

Yes.

spillbean:

an interface containing 30 methods

 

Is unreasonable. Split it up.

Hi Svante, Can you be a little descriptive?

I want to know whether I can simultaneously avoid all the methods of an interface to be implemented and prevent the class to be abstract.

What benefit will I get by splitting up the interface?

ok Svante, I somewhat got you....but can I know how many members maximum does an inbuilt Interface of .NET has?

And how can I split an inbuilt interface of .NET like IEnumerable or anything like that  ?

 

 

 

spillbean:

Can you be a little descriptive

 

All too often, I'm way too descriptive... But sure!

spillbean:

I want to know whether I can simultaneously avoid all the methods of an interface to be implemented and prevent the class to be abstract.

 

As mentioned, no. But... As someone once said "these are not the droids you are looking for", perhaps. You really have two major options:

1. Implement the interface in a base class, but have all (or most, whatever) of the implementations throw a NotImplementedException.  Then you can derive from that concrete base class and override whatever you need to actually implement. This is a rather dangerous course, because you never know when the flow of control will reach one of this NotImplementedException methods and your app blows up in production. I'd probably not recommend this course of action unless you have no other choice (i.e. you did not define the interface, and you can't change it).
   
2. Split up the interface in smaller parts. In a good desing, an interface describes a rather generic ability that is likely or at least conceivable to be shared by many rather different types. For example IXmlSerializable describes the rather generic ability to be serialized as XML. IEquatable the rather generic ability to be compared. So, you should strive to think of interfaces as such capabilities. If this does not fit, an interface may not be the droid you are looking for. If the capabilities of your 30-method interface still fall into such generic capabilities, it's rather unlikely that it really is one capability. It's more likely to be a composition of maybe 5-15 capabilities, and then you should instead define discrete smaller interfaces and then you only need to implement the relevante interface(s) for your concrete classes.

spillbean:

What benefit will I get by splitting up the interface

Apart from a cleaner and more easily maintained design, you'll gain the benefit you're looking for - the ability to only implement a few of the 30 methods and still get a concrete implementation of your class.

As an example, let's assume you have the following:

 

public interface ICreature
{
  void MakeSound();
  int Height { get; }
  BitMap Picture { get; }
}

  This is a hypothetical interface of a creature in a role playing game. Looks ok, but... Is the capability to render oneself as bitmap really integral to the concept of a creature? I'd rather split this interface:

  

public interface ICreature
{
  void MakeSound();
  int Height { get; }
}

public interface IVisible
{
  BitMap Picture { get; }
}

 Now I can choose to implement one, the other or both of the interfaces in my concrete classes.

I'd probably continue and factor out the ability to make sound as well in a IAudible interface.

For common combinations, you can always combine interfaces since an interface may inherit from more than one interface, i.e.

 

public interface IInteractiveCreature : IVisible, IAudible
{
  int Height { get; }
}

  

spillbean:

can I know how many members maximum does an inbuilt Interface of .NET has

 

As far as I know there's no set limit in the C# language. I don't know offhand what the largest interface in the framework library is, but I guess one could write a small program to find out via reflection - if that was your question.

spillbean:

And how can I split an inbuilt interface of .NET like IEnumerable or anything like that  ?

 

You cannot split an interface that you do not control the source code for. As for IEnumerable specifically, it only has one method so there's nothing to separate out.

Svante, Thanks for the answer. It really helped me.

1) As everyone else has said, yes you need to implement all the interface methods and properties.

2) The guideline I've heard for interface size is generally no more than 5 members.  This is however a guideline and not a hard rule.  My personal guideline is that if you cant put the interface name in terms of an adverb it's probably either too big or something that should just be an abstract base class.  

3) I dont see why you'd want to "prevent the class from being abstract".  Abstract base classes which implement most of a corresponding interface in a common way are often very, very useful. 

spillbean:

Svante, Thanks for the  answer, my problem is almost solved.

 Now one last question. Can we apply this splitting up concept to any of the inbuilt interfaces of .NET ?

If yes then how can I do that?

Thanks in advance......

 

 

No, you cant.  As was said, if you do not control the source to the interface you cant change it.  However I cant think of an interface in the framework that is that poorly designed.  

spillbean:

Can we apply this splitting up concept to any of the inbuilt interfaces of .NET ?

 

As previously mentioned, no.

But you can define a concrete type implementing the interface in question, and either derive from it and only override the specific methods you need, or more realistically, use that partial but concrete implementation, and then compose it (wrap an instance) with whatever class you're really implementing, and let that class implement the interface, but delegate all the work to the wrapped instance. I.e:

 

public interface IMyInterface
{
  void MyMethod1();
  void MyMethod2();
}

public class MyConcreteInterface : IMyInterface
{
  public void MyMethod1()
  {
    throw new NotImplementedException();
  }
  public void MyMethod2()
  {
    throw new NotImplementedException();
  }
}

public class MyPartialImplementation : MyConcreteInterface
{
  public override void MyMethod1()
  {
    // Do something here
  }
}

public MyRealClass : IMyInterface
{
  private MyPartialImplemenation myImplementation = new MyPartialImplementation();

  public void MyMethod1()
  {
    myImplementation.MyMethod1();
  }

  public void MyMethod2()
  {
    myImplementation.MyMethod2();
  }
}

  At the expense of some boiler plate code, you have now gained the capability to 'partially' implement an interface that you cannot change.

 Svante, Jeffrey..and all those who answered.....Thank you guys for being helpful. I was Googling around about  this concept for  quite sometime. But was not able to find a suitable answer and this is where I cleared my doubts.

Thank you very much guys.