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?
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).