By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,742 Members | 2,026 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,742 IT Pros & Developers. It's quick & easy.

Interface

P: n/a
Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?

If I am wrong, can someone please explain me what exactly is an
interface?

Thanks

Oct 3 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On Oct 3, 2:16 pm, r...@rediffmail.com wrote:
Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?

If I am wrong, can someone please explain me what exactly is an
interface?

Thanks
I mean what exactly is an interface as far as object-oriented
programming is concerned?

Oct 3 '07 #2

P: n/a
A good place to start:
http://msdn2.microsoft.com/en-us/lib...5b(VS.80).aspx
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"rn**@rediffmail.com" wrote:
On Oct 3, 2:16 pm, r...@rediffmail.com wrote:
Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?

If I am wrong, can someone please explain me what exactly is an
interface?

Thanks

I mean what exactly is an interface as far as object-oriented
programming is concerned?

Oct 3 '07 #3

P: n/a
an interface is a contract of method signatures defined with an
abstract class (defines methods only). ain turn class specifies that it
will implement the interface.

as your sample does not specify any interfaces that it will implement,
it has none. now assume interface:

// c# - don't know vb well enough
public interface IQuery
{
SqlDataReader QueryDB(string q);
}

and you changed your code to:

Public Class DBSettings implements IQuery

then your class would have implemted interface IQuery and could be cast
as an IQuery.

-- bruce (sqlwork.com)
rn**@rediffmail.com wrote:
On Oct 3, 2:16 pm, r...@rediffmail.com wrote:
>Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?

If I am wrong, can someone please explain me what exactly is an
interface?

Thanks

I mean what exactly is an interface as far as object-oriented
programming is concerned?
Oct 3 '07 #4

P: n/a
rn**@rediffmail.com wrote:
Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?
No.
If I am wrong, can someone please explain me what exactly is an
interface?
An interface is a contract that a class can implement. It can contain
the defintions of methods and properties, but no methods and no data.

You could for example create this interface, that your DBSettings class
could implement:

Public Interface IDBSettings
Public Function QueryDB(qry As String) As SqlDataReader
End Interface

The point is that you can write code that makes use of the interface,
without caring what the actual class is that implements it. That in turn
means that you can write that code even before there is a class that
implements the interface, and also that you can create different classes
that implement the interface.

--
Göran Andersson
_____
http://www.guffa.com
Oct 3 '07 #5

P: n/a
For your example, there is no explicit interface, but if there were one it
would be

Public Interface IDatabase
Public Function QueryDB(qry As String) As SqlDataReader
End Interface

Your class, to use this interface, would be

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings Implements IDatabase
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

I may have this a bit off, as I normally work in C#, but the basics are
there.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
<rn**@rediffmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...
On Oct 3, 2:16 pm, r...@rediffmail.com wrote:
>Suppose I have the following class code:

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Class DBSettings
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection
Public ConnectionString As String

Public Function QueryDB(qry As String) As SqlDataReader
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader

sqlConn.Close()
End Function
End Class

Now all the code that exists in the above class (between the lines
Public Class DBSettings & End Class) - is that what is called the
interface?

If I am wrong, can someone please explain me what exactly is an
interface?

Thanks

I mean what exactly is an interface as far as object-oriented
programming is concerned?

Oct 3 '07 #6

P: n/a
rn**@rediffmail.com wrote:
>(The method is unusable, though, as the database connection has to be
open while you read from the data reader.)

Goran, why is the method unusable? I have explicitly opened the
database connection to read from the data reader.
You open the connection, create the reader, then close the connection.
As the reader needs the connection to be open, it unusable after the
connection has been closed. When the method returns the reader, it's no
longer possible to read anything from it.
>Dim dbs as IDBSettings

dbs = New DBSettings()

Now you have a reference to the interface, but it points to an instance
of the class.

But why would a programmer do something like what you have shown
(reference to an interface but pointing to an instance of a class)
when the same can be done without referencing the interface like this?

Dim dbs As DBSettings
dbs = New DBSettings()
It's just an example to show that the reference can be a reference to an
interface instead of a reference to the class. It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface).
>An interface is usually used to specify some behaviour. You can for
example use the IComparer interface to specify that a class is capable
of comparing two values, and then use that class in a call to Array.Sort
to provide tha comparison method for the sorting.

If I am not mistaken, a class is also used to specify some behavior
(please correct me if I am wrong).
A regular class just have some behaviour, it doesn't define behaviour
for other classes.

An abstract class on the other hand, can both define behaviour for
derived classes, and implement behaviour itself. An abstract class that
doesn't implement anything itself is similar to an interface.
A class comparing 2 values can also
be created without using the IComparer interface. So why use an
interface?
Yes, you can make a class that compares two values, but you can't make
the Array.Sort aware of the fact that the class can do this if you don't
use the interface.
BTW, when I use the code that I have shown in my previous post (which
has the interface & the class that implements the interface) in a
class (.vb) file (removing the "Public" keyword while declaring the
method QueryDB in the interface since Public is not valid on interface
method declaration),
Right. I missed to remove the access modifier in the interface. You
can't specify any access level in an interface as everything is always
public.
then the error "End of statement expected" gets
generated pointing to the line shown below:

Public Class DBSettings Implements IDBSettings

What's causing that error?
You have to put them on separate lines:

Public Class DBSettings
Implements IDBSettings

You also have to specify Implements on the method:

Public Function QueryDB(ByVal qry As String) As SqlDataReader Implements
IDBSettings.QueryDB

(I usually do this in C#, that isn't line based, and that just
identifies the methods for the implementation by name.)

--
Göran Andersson
_____
http://www.guffa.com
Oct 4 '07 #7

P: n/a
On Oct 4, 7:14 am, Göran Andersson <gu...@guffa.comwrote:
r...@rediffmail.com wrote:
(The method is unusable, though, as the database connection has to be
open while you read from the data reader.)
Goran, why is the method unusable? I have explicitly opened the
database connection to read from the data reader.

You open the connection, create the reader, then close the connection.
As the reader needs the connection to be open, it unusable after the
connection has been closed. When the method returns the reader, it's no
longer possible to read anything from it.
Dim dbs as IDBSettings
dbs = New DBSettings()
Now you have a reference to the interface, but it points to an instance
of the class.
But why would a programmer do something like what you have shown
(reference to an interface but pointing to an instance of a class)
when the same can be done without referencing the interface like this?
Dim dbs As DBSettings
dbs = New DBSettings()

It's just an example to show that the reference can be a reference to an
interface instead of a reference to the class. It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface).
An interface is usually used to specify some behaviour. You can for
example use the IComparer interface to specify that a class is capable
of comparing two values, and then use that class in a call to Array.Sort
to provide tha comparison method for the sorting.
If I am not mistaken, a class is also used to specify some behavior
(please correct me if I am wrong).

A regular class just have some behaviour, it doesn't define behaviour
for other classes.

An abstract class on the other hand, can both define behaviour for
derived classes, and implement behaviour itself. An abstract class that
doesn't implement anything itself is similar to an interface.
A class comparing 2 values can also
be created without using the IComparer interface. So why use an
interface?

Yes, you can make a class that compares two values, but you can't make
the Array.Sort aware of the fact that the class can do this if you don't
use the interface.
BTW, when I use the code that I have shown in my previous post (which
has the interface & the class that implements the interface) in a
class (.vb) file (removing the "Public" keyword while declaring the
method QueryDB in the interface since Public is not valid on interface
method declaration),

Right. I missed to remove the access modifier in the interface. You
can't specify any access level in an interface as everything is always
public.
then the error "End of statement expected" gets
generated pointing to the line shown below:
Public Class DBSettings Implements IDBSettings
What's causing that error?

You have to put them on separate lines:

Public Class DBSettings
Implements IDBSettings

You also have to specify Implements on the method:

Public Function QueryDB(ByVal qry As String) As SqlDataReader Implements
IDBSettings.QueryDB

(I usually do this in C#, that isn't line based, and that just
identifies the methods for the implementation by name.)

--
Göran Andersson
_____http://www.guffa.com
Goran, I am highly obliged to you for putting in so much effort & time
in trying to make me understand interfaces. I really appreciate it
from the bottom of my heart (& I really mean it). Now I am getting a
hang of interfaces & their uses. I guess you must be pleased to know
that your efforts aren't being wasted!

Finally I could make that code work. This is the class (.vb) code (I
am reproducing the entire code so that someone else can benefit from
it in the future; after all everyone won't be as fortunate as me to
have a helpful guide like you):

Imports System
Imports System.Data
Imports System.Data.SqlClient

Public Interface IDBSettings
Property ConnectionString() As String
Function QueryDB(ByVal qry As String) As SqlDataReader
End Interface

Public Class DBSettings
Implements IDBSettings
Public ConnString As String
Private sqlCmd As SqlCommand
Private sqlConn As SqlConnection

Public Property ConnectionString() As String Implements
IDBSettings.ConnectionString
Get
ConnectionString = ConnString
End Get
Set(ByVal value As String)
ConnString = value
End Set
End Property

Public Function QueryDB(ByVal qry As String) As SqlDataReader
Implements IDBSettings.QueryDB
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader
sqlConn.Close()
End Function
End Class

& this is the ASPX code:

<%@ Page Language="VB" Explicit="True" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>

<script runat="server">
Sub Page_Load(ByVal obj As Object, ByVal ea As EventArgs)
Dim boDBSettings As IDBSettings
Dim sqlDReader As SqlDataReader

boDBSettings = New DBSettings
boDBSettings.ConnectionString = ".........."
sqlDReader = boDBSettings.QueryDB("SELECT * FROM Table1")

If Not (sqlDReader Is Nothing) Then
dg1.DataSource = sqlDReader
dg1.DataBind()

sqlDReader.Close()
End If
End Sub
</script>
<form runat="server">
<asp:DataGrid ID="dg1" runat="server"/>
</form>

There is one thing I noticed when I made the reference to the
IDBSettings interface (instead of the DBSettings class) in the ASPX
code. I use Visual Web Developer 2005 for ASP.NET apps. When I typed

boDBSettings.

(notice the dot after boDBSettings), then VWD's intellisense lists
only 2 items - the property named ConnectionString & the function
named QueryDB but if I make the reference to the DBSettings class,
then apart from ConnectionString & QueryDB, VWD's intellisense also
lists other items like ConnString, Equals, GetHashCode, GetType,
ReferenceEquals, ToString etc.

So isn't this a disadvantage of using user-defined interfaces? Because
making a reference to the interface IDBSettings from the ASPX page
means I won't be able to use the built-in functions like Equals,
GetHashCode, GetType etc. (which would be available if I make the
reference to the DBSettings class instead). If I want to do the same
task which the function, say, Equals does, then I have to add more
code within the interface & the class (in the class file) which in
turn means more work for the programmer. So is using user-defined
interfaces worthwhile?
It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface)
Sorry, Goran, I couldn't exactly understand the above statement. Could
you please elaborate on it a little bit (maybe with an example as I
find it easier to understand things with examples instead of just a
textual explanation)?

Thanks once again for your co-operation.

Regards.

Oct 5 '07 #8

P: n/a
rn**@rediffmail.com wrote:
Finally I could make that code work. This is the class (.vb) code (I
am reproducing the entire code so that someone else can benefit from
it in the future; after all everyone won't be as fortunate as me to
have a helpful guide like you):
8< snip
Public Function QueryDB(ByVal qry As String) As SqlDataReader
Implements IDBSettings.QueryDB
sqlConn = New SqlConnection(ConnectionString)
sqlCmd = New SqlCommand(qry, sqlConn)

sqlConn.Open()
Return sqlCmd.ExecuteReader
sqlConn.Close()
You are still closing the connection. The data reader will not be able
to read any data from the database. It may work if the result is very
small so that it fits in the data buffer, but that's not a reasonable
limitation for a method like this.

You either have to specify CommandBehaviour.CloseConnection so that the
connection is closed when the data reader is closed, or supply another
method that can be used to close the connection after the data has been
read.
End Function
End Class
8< snip
There is one thing I noticed when I made the reference to the
IDBSettings interface (instead of the DBSettings class) in the ASPX
code. I use Visual Web Developer 2005 for ASP.NET apps. When I typed

boDBSettings.

(notice the dot after boDBSettings), then VWD's intellisense lists
only 2 items - the property named ConnectionString & the function
named QueryDB but if I make the reference to the DBSettings class,
then apart from ConnectionString & QueryDB, VWD's intellisense also
lists other items like ConnString, Equals, GetHashCode, GetType,
ReferenceEquals, ToString etc.

So isn't this a disadvantage of using user-defined interfaces? Because
making a reference to the interface IDBSettings from the ASPX page
means I won't be able to use the built-in functions like Equals,
GetHashCode, GetType etc. (which would be available if I make the
reference to the DBSettings class instead). If I want to do the same
task which the function, say, Equals does, then I have to add more
code within the interface & the class (in the class file) which in
turn means more work for the programmer. So is using user-defined
interfaces worthwhile?
As you are using the interface where you just as well could use the
class, you don't see the benefits of using an interface.
>It's of course only
useful when one method creates the object and another method uses the
object (in the shape of the interface)

Sorry, Goran, I couldn't exactly understand the above statement. Could
you please elaborate on it a little bit (maybe with an example as I
find it easier to understand things with examples instead of just a
textual explanation)?
If you are creating the instance of the class in the same method as you
use it, it's rarely useful to use the interface at all. It's when you
create the instance in one method and sends it to another method that
there are any benefits.

This is used more often than most people know, for example if you create
a list from an array:

int[] values = new int[] { 1, 2, 3, 4 };
List<intlist = new List<int>(values);

(Sorry about the C# code, but that's what I usually use. Hope you can
follow it.)

The constructor of the List class doesn't take an array as argument, it
takes in IEnumerable. That way there only has to be one constructor that
creates a List from a collection of values, instead of one for Array,
one for List, one for Queue, one for Stack, one for SortedList, one for
Dictionary, one for LinkedList, one for SortedDictionary... and so on.

When you call the constructor for the List with an array, the reference
is not sent as a reference to an array, it's sent as a reference to
IEnumerable. By using the array in the call, you are implicitly casting
it into the interface before it's sent to the constructor.

The List constructor that uses the interface doesn't care if it's
actually an Array, a List, a Stack, a Queue... etc. that is implementing
the interface. It only cares about what the interface offers, i.e. that
it can loop through the items in the collection and get the values.

--
Göran Andersson
_____
http://www.guffa.com
Oct 7 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.