Printable View
Hello all,
I am wonder what .Net does internally when you have an object cast as an interface it inherits and what happens when you call the interface's method.
Example:
...
IDBCommand.ExecuteReader(...);
...
This will execute sql command with no issue against a IDBConnection, assuming everything else is setup correctly. Does anyone have any leads or good explainations on how this occurs?
Any one have any information on this at all?
well, this doesn't ever really get called: IDBCommand.ExecuteReader(...);
what gets called is your_class_instance.ExecuteReader(...);
and you don't inherit an interface... interfaces are implemented. Now, once it's been implemented, the implementing class can be inherited. But then you're inheriting the class, not the interface.
Interfaces are nothing magical really. There's nothing special that goes on behind the scenes, not notably at any rate. The point of interfaces is to enforce a contract between caller and callee. If I know that a particular class implements ISomething then I can be guaranteed that when I call .DoSomething ... there will be a DoSomething method to be called. I don't care what DoSomething does, or if it even does something. All I know is that that method exists, and has the given signature. It's a way to allow for binding and prevents blind calls.
Example: both OLEDB and SQLClient have an ExecuteReader method... that's because both classes implement the IDBCommand interface. That means I can Dim someDBCallee as IDBCommand ... and then use EITHER SQLClient OR OLEDB classes to create a command object... then I can just call someDBCallee.ExecuteReader ... w/o caring how it does it (Access vs SQL Server) ... all I know is that ExecuteReader will execute the command and return a Reader object....
-tg
Thank you for your response.
Could you clairify how the CLR determines what the underlying object is and its implementation of the contract method?