Instantiating from an Interface?

  • Thread starter Thread starter Scott Johnson
  • Start date Start date
S

Scott Johnson

I thought interfaces have no implementation so how can I create a DataReader
from an IDataReader Interface and use it similarly to how I would use an
OleDBDataReader? How is it that the block of code below actually functions?
Does IDataReader have an implementation or not? Thanks in advance.

System.Data.IDataReader DR= db.ExecuteReader(dbCommandWrapper);
while(DR.Read())
{
Console.WriteLine(DR.GetValue(0).ToString() );
}
 
Hi Scott,

The ExecuteReader call creates an instance which implements the
IDataReader interface.

Succes,
Bart
 
Hi Scott,

The ExecuteReader call creates an instance which implements the
IDataReader interface.

Succes,
Bart
 
I thought interfaces have no implementation so how can I create a DataReader
from an IDataReader Interface and use it similarly to how I would use an
OleDBDataReader? How is it that the block of code below actually functions?
Does IDataReader have an implementation or not? Thanks in advance.

System.Data.IDataReader DR= db.ExecuteReader(dbCommandWrapper);
while(DR.Read())
{
Console.WriteLine(DR.GetValue(0).ToString() );
}
Click to expand...

The return from ExecuteReader will be an object that implements the
IDataReader interface. In the case of an OleDbCommand object, it returns
an OleDbDataReader which implements IDataReader along with IDataRecord and
other interfaces.
 
What might be tripping you up is that it's a little confusing that
interfaces are also types, even though they don't describe an entire
type as such. They are more of a partial type, or even more accurately,
a template specification for a partial type. Or more accurately yet, a
description of part of the interface of a type.

What you're actually getting back from that call to ExecuteReader() is
some instance of a class that, amongst other things, implements the
IDataReader interface. But you're viewing that instance through the
"lens" of the interface. Using the interface "type" lets you work with
any object that implements the interface, but you can only "see" and
work with the portion of the object that implements the interface. Even
though the complete instance with all its data and behaviors is in
memory, you can't get to all of it.

Really, when you think about it, interfaces are a way to partially get
around the restrictions of strong typing when the exact full type of an
object isn't known at design time. Unlike .NET, loosely typed,
late-bound environments have less need to support interfaces because the
runtime cares more about what the object *does* than what it *is*. So
if you call Foo() on some object in a loosely typed, late-bound
environment, all that matters is that the object has a Foo() method, and
you'll only get an error if the object lacks the method. Whereas in
..NET, everything is wired up at compile time. Interfaces are a way to
assure the compiler that while the object's type can't be known to the
compiler, it is at least known to implement Foo().

--Bob
 
Hello Scott!

What actually is going on is that "ExecuteReader()" method returns an
object which implements "IDataReader" interface. This is basic of
polymorphism.

Onething to keep in mind that, if the object that ExecuteReader()
returns has some methods of its own then they wont be available with
IDataReader type-instance, since those operations are specialized to
the object that ExecuteReader() returns

For the sake of example lets conside the following code:

1) We have a TaskManager class which has a public method DoAction which
returns an instance of IAction (just like ExecuteReader returns an
instance of IDataReader)

public class TaskManager
{
public IAction DoAction()
{
// Do something here and return one of the 2 IAction
implementation
// i.e. either returns a reference of InsertAction class
// or that of UpdateAction class
// return new InsertAction();
// return new UpdateAction();
}
}

2) IAction interface

public interface IAction
{
int Execute();
}

3) IAction interface implementations

public class InsertAction : IAction
{
public int Execute()
{
// Insert something in database and return
}

// Specialized method
public void InsertTest()
{
// Do something
}
}

public class UpdateAction : IAction
{
public int Execute()
{
// Update something in database and return
}

// Specialized method
public void UpdateTest()
{
// Do something
}
}

4) Client Code:

public class MainClass
{
public static void Main()
{
TaskManager taskMan = new TaskManager();
// This is the key point -- so pay attention
IAction action = taskManager.DoAction();
Console.WriteLine(action.ExecuteAction());
}
}

Note: After casting to IAction we have lost the identity that it is an
"InsertAction" or an "UpdateAction" so their specialized
operation/method [InsertTest()/UpdateTest()] cant be called.

Hope this might be of some help. Let me know in case of any
inconsistancy.

Regards,

Moiz Uddin Shaikh
Software Engineer
Kalsoft (Pvt) Ltd
 
Back
Top