CODEWITHSUNDEEP
c#interfaceconstructordestructor
Kuntady Nithesh
Kuntady Nithesh

Reputation: 11721

Why can't an interface have constructors and destructors?

I know the interface is working. When I started coding in my project, I got this doubt in my mind. Can anyone clarify ?

Upvotes: 7

Views: 8368

Answers (10)

S. P. Singh
S. P. Singh

Reputation: 1

It's true that Interface doesn't have a constructor as they don't have any idea as to what type of derived class going to implement it.

But we can have a virtual destructor in case we don't want the compiler to implicitly create a move operation.

Upvotes: 0

Thomas Ley
Thomas Ley

Reputation: 86

I did another approach, the "what if..." question. And this is my conclusion (from my blog):

1st: Given is an interface IApp which defines a constructor "ctor(int)".

2nd: A class MyApp is defined and implements IApp.

==> Class MyApp now has a constructor "ctor(int)" from IApp

3rd: Given is a second interface ICoolApp which defines a constructor "ctor(string)"

4th: Class MyApp implements ICoolApp. ==> Class MyApp has now two constructors "ctor(int)" and "ctor(string)". So far so good.

Even if there would be constructors with the same signature defined, an explicit implementation can define two different ways to create the class MyApp (as it works with methods already).

5th: A new instance of MyApp ist created calling "new MyClass(int)". This new instance is an IApp and and ICoolApp because it implements both interfaces. No problems, right?

==> Wrong! The class MyApp has two constructors, but the instance was created by calling IApp's constructor. The constructor "ctor(string)" to fulfill ICoolApp's way of creating objects was not called.

As a conclusion, the instance of MyApp is both, an IApp and ICoolApp, but the creation of the instance only fulfilled one contract, the contract of IApp. And because of different signatures, it is not possible to fulfill both contracts at the same time during instance creation, although MyApp claims to respect/implement both contract.

Upvotes: 3

Xose Lluis
Xose Lluis

Reputation: 915

I've also asked myself this question a few times, and one explanation seems to come to mind now:

The Interface contract describe **What** the object does, not **How** to do it. The constructor probably has more to do with the How, so that's why we can't make it part of the contract.

The clients of an interface expect to receive an already constructed object, so they don't care about the constructor signature. As for the code that will create that object, it already knows what concrete object to create, so it knows the constructor signature.

Upvotes: 0

supercat
supercat

Reputation: 81149

It is possible to define a static class, with a name similar to the interface, that includes factory methods or properties to generate class instances that implement the interface. Examples of this include Enumerable<T>.Empty and Comparer<T>.Default. I personally think it would be helpful if there were a means of specifying that an interface name should be usable to refer to static members (either by having an interface and static class of the same name, being able to include static members within an interface, being able to designate a static class as being 'associated' with an interfafce, or whatever). Unfortunately, I am unaware of such a facility in any .net language; the best one can do is use a static class with a similar name (as with IEnumerable/Enumerable and IComparer/Comparer).

Incidentally, a nice bonus feature if interfaces could include statics would be a means of having them include extension methods for themselves. For example:

  void SetBounds(int x, int y, int width, int height, BoundsSpecified specified);
  static void SetBounds(int x, int y, int width, int height)
    { It.SetBounds(x, y, width, height, BoundsSpecified.All); }
  static void SetSize(int width, int height)
    { It.SetBounds(0, 0, width, height, BoundsSpecified.Size); }

to allow an interface to expose to its users many overloaded versions of common functions without requiring all implementations to include the boilerplate code necessary to implement them.

Upvotes: 0

Lonli-Lokli
Lonli-Lokli

Reputation: 3766

As I understand, you want to know why we can't specify constructor's signature as well as other object's methods, like

    interface IApp
    {
         void App(int i, int j);
    }
    class App : IApp
    {
         // You want constructor to be only with 2 parameters
         public void App(int i, int j){ }
    }

It can't be done because at first, all interface methods should be implemented as public but constructors can be set as private, and at second, method void App(..) will be constructor only for class App, for another class it will be another method.

So in common, if you want to specify constructor with known parameters, try to use abstract base classes.

Upvotes: 3

paulsm4
paulsm4

Reputation: 121649

I agree that interfaces are a "contract". And personally, I'd like to be able to specify constructor signatures as part of that contract.

But heck, I like languages like Pascal and Ada, which both go to great lengths to specify a formal "interface", separate and distinct from the "implementation".

For whatever it's worth, there are several practical as well as theoretical reasons for excluding constructors - or even constructor definitions - from interfaces. The arguments are basically the same for C# as they are for Java. This link is instructive:

I pretty much agree with these sentiments:

Upvotes: 0

mrjoltcola
mrjoltcola

Reputation: 20842

Because an interface is nothing to construct or destruct. It is simply an idea. A contract.

The construction of an interface is the act of declaring & defining it. They are not objects to be instantiated.

Upvotes: 0

i_am_jorf
i_am_jorf

Reputation: 54600

Interfaces are just contracts between objects. They don't have any code. Giving them constructors and destructors would be giving them code to run. If you need initialization or cleanup in your contract, you add an Initialize() and Uninitialize() method.

Upvotes: 0

Pranay Rana
Pranay Rana

Reputation: 176896

Interface defines set of the methods will can be implemented by the one or more classes. Its abstact from that defines the contract.

Interface doesnt allocate any memory or implement any methods

Interface doesnt have any functionality to initialize the variable in that.

Upvotes: 1

Darin Dimitrov
Darin Dimitrov

Reputation: 1038770

Interfaces are contracts, not implementations, so no need to construct or destroy them. You only construct and destroy concrete types which could implement interfaces.

Upvotes: 23

Related Questions