7

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

Mark Hall
  • 53,938
  • 9
  • 94
  • 111
Kuntady Nithesh
  • 11,371
  • 20
  • 63
  • 86

10 Answers10

23

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

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
3

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.

Thomas Ley
  • 76
  • 4
  • I can't really understand your point. About 5th. I create a MyApp instance using "new MyApp(int)". Now I have an instance of MyApp that implements both interfaces. What do you mean by "The constructor 'ctor(string)' was not called"? Ok, it was not called because the instance was created with the other ctor. And so? What's the point? What's the problem? If you have a class that implements two methods from two different interfaces, calling one method doesn't mean that the object don't respect anymore the other interface's contract. – Massimiliano Kraus Sep 28 '16 at 18:48
  • 1
    @MassimilianoKraus his point is that both interfaces have an 'expectation' of how the object will be created. Due to implementing both interfaces, it is impossible to satisfy both interfaces unless whoever implements both constructors takes care of it. This is actually the best explanation in here, in my opinion. Although a bit unstructured. – Steffen Winkler Aug 23 '19 at 09:41
3

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.

Lonli-Lokli
  • 3,357
  • 1
  • 24
  • 40
  • 3
    Minor point, but other methods can be set private too. When they implement an interface they have to be public as you said, but constructors really aren't any different in terms of visibility they can have. – Adam Lear Aug 29 '11 at 13:42
  • 1) As @AdamLear said, every method can be public or private. 2) Even using an abstract class you can have private constructors in the derivatives, so what's your point?. 3) the constructor in the interface "IApp" should be "IApp(int i, int j)", not "App(int i, int j)", otherwise an App2 implementing IApp should contain a constructor called "App" (??). Downvote. – Massimiliano Kraus Sep 28 '16 at 18:39
1

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.

Pranay Rana
  • 175,020
  • 35
  • 237
  • 263
0

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.

Xose Lluis
  • 895
  • 1
  • 9
  • 8
0

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.

S. P. Singh
  • 1
  • 3
0

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.

i_am_jorf
  • 53,608
  • 15
  • 131
  • 222
0

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.

codenheim
  • 20,467
  • 1
  • 59
  • 80
0

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:

paulsm4
  • 114,292
  • 17
  • 138
  • 190
0

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.

supercat
  • 77,689
  • 9
  • 166
  • 211