Why does the interface have no constructors or destructors?

Question

I know the interface is working. When I started coding in my project, I had such a doubt. Can anyone clarify?

Answer 1

As I understand it, you want to know why we cannot specify the signature of the constructor, as well as other object methods, for example

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){ } } 

This cannot be done, because at first all the interface methods must be implemented as public, but the constructors can be set as private, and secondly, the void App (..) method will be a constructor only for the App class, for another class it will be a different method .

So, if you want to specify a constructor with known parameters, try using abstract base classes.

Answer 2

Interfaces are contracts, not implementations, so there is no need to create or destroy them. You only create and destroy specific types that interfaces can implement.

Answer 3

The interface determines that a set of methods can be implemented by one or more classes. His abstraction from this defines the contract.

The interface does not allocate any memory or implement any methods

The interface has no functions to initialize this variable.

Answer 4

Interfaces are simply contracts between objects. They have no code. Providing them with constructors and destructors will give them code to run. If you need initialization or cleanup in your contract, you add the Initialize () and Uninitialize () methods.

Answer 5

Because the interface does not mean to build or destroy anything. This is just an idea. The contract.

Building an interface is the act of declaring and defining it. They are not objects to create instances.

Answer 6

I agree that interfaces are a “contract”. And personally, I would like to be able to specify the signature of the constructor as part of this contract.

But hell, I like languages ​​like Pascal and Ada, which both go to great lengths to indicate a formal “interface” that is separate and distinct from the “implementation”.

Whatever the cost, 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 largely agree with these feelings:

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

Answer 7

You can define a static class with a name similar to an interface, which includes factory methods or properties to generate instances of the class that implement the interface. Examples of this include Enumerable <T> .Empty and Comparer <T> .Default. I personally think that it would be useful if there was a means to indicate that the interface name should be used to refer to static members (either using the interface and a static class with the same name that can include static elements in the interface, being able to indicate static class as "related" to interfafce or something else). Unfortunately, I do not know such an object in any .net language; the best thing that can be done is to use a static class with a similar name (as with IEnumerable / Enumerable and IComparer / Comparer).

By the way, a good bonus function, if the interfaces can include statics, will be a means of incorporating extension methods for themselves. For instance:

  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 the interface to provide its users with many overloaded versions of common functions, without requiring that all implementations include the template code needed to implement them.

Answer 8

I also asked myself this question several times, and now I come up with one explanation:

The interface contract describes ** What ** the object does, not ** How ** does it. The constructor probably has more in common with How, so we cannot make it part of the contract.

Interface clients expect to receive an already constructed object, so they do not need a constructor signature. As for the code that will create this object, it already knows which specific object to create, so it knows the signature of the constructor.

Answer 9

I took a different approach, the question "what if ...". And this is my conclusion ( from my blog ):

1st: this is an IApp interface that defines the constructor "ctor (int)".

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

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

3rd: this is the second ICoolApp interface that defines the constructor "ctor (string)"

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

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

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

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

As a conclusion, the MyApp instance is both IApp and ICoolApp, but the instantiation performed only one contract - the IApp contract. And because of the different signatures, it is not possible to simultaneously execute both contracts when creating an instance, although MyApp claims to comply / implement both contracts.