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 do开发者_Python百科ubt in my mind. Can anyone clarify ?

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

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.

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.

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.

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.

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.

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:

• http://c2.com/cgi/wiki?JavaInterfacesCannotSpecifyConstructors

I pretty much agree with these sentiments:

• http://zoom.z3950.org/bind/java/comment/constructor.html

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.

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.

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.