1

I understand that an interface is an abstract type that contains no data, but exposes behaviours and properties, and that an instance of an object is an occurrence or a copy of an object that exists in memory.

I'm wondering about the differences in how the compiler / underlying code deals with the two? Based on the answer to this, why is the code more loosely coupled if I pass an interface as a dependency to an object rather than a concrete instance? What is the difference between what happens if I call the DoSomething method defined in an Interface to MyClass rather than the DoSomething method defined in the concrete instance of MyClass?

DaveDev
  • 41,155
  • 72
  • 223
  • 385
  • I think your question is nicely answered here: http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_interrfaces03052006095933AM/csharp_interrfaces.aspx – Michal B. Apr 24 '12 at 10:40
  • 2
    @MichalB.: I'm not so sure. That just explains interfaces and how they can be used / how they are useful. It says nothing of the CLR / compiler. – George Duckett Apr 24 '12 at 10:48
  • See the excellent top-rated answer to this question for some backgound: [CLR implementation of virtual method calls to interface members](http://stackoverflow.com/q/9808982). (Second link googling for `interfaces implementation CLR`) – George Duckett Apr 24 '12 at 10:50
  • possible duplicate of [CLR implementation of virtual method calls to interface members](http://stackoverflow.com/questions/9808982/clr-implementation-of-virtual-method-calls-to-interface-members) – Oded Apr 24 '12 at 10:52

3 Answers3

1

I know you said you understood what an interface is - but I do wonder if that's entirely true given the way that you've linked your second question with the first. The second can be answered without any knowledge of the first, nor is it influenced in any way by it.

Specifically on the question of why it's more loosely coupled has nothing to do with the implementation of the compiler or anything: it's just software architecture.

Interfaces impose no restrictions on the implementing type other than the presence of the method/property (well, technically they're methods too).

The implementation doesn't even have to be public on the type itself, nor does the type have to have a certain constructor etc. More importantly - it doesn't even have to be a class. Then there's the (rather edge-case) thing that with interfaces a single type can have multiple implementations of the same interface.

As soon as you use a base class potentially introduce a whole load of other restrictions.

True, these can clearly be a good thing too - for example if a known concrete base is known to be immutable (for consistency) and which doesn't allow 'nulls' in it's constructor etc (all not enforcable through an interface).

Andras Zoltan
  • 41,961
  • 13
  • 104
  • 160
0

You can have many implementations (concrete instances) of an interface or abstract class.

In general you should define methods that accept the class hierarchy with the interface and not the concrete classes, so that they will be generic and wont have to be rewritten for each new implementation you define.

Calling the method on the base class or in the derived class should call the same method, assuming you correctly override the method.

Brady
  • 10,207
  • 2
  • 20
  • 59
  • 6
    The question is how the CLR treats the differences, not what the differences are. – Oded Apr 24 '12 at 10:42
0

Have a look at the MSDN magazine article: "Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects" for implementation details.
I think the main reason why the runtime needs to support interfaces is especially related to the fact that assemblies with different compile times might connect to each other at runtime.

weismat
  • 7,195
  • 3
  • 43
  • 58