Interface based programming

  • Thread starter Thread starter Ricky W. Hunt
  • Start date Start date
R

Ricky W. Hunt

It's dawning on my a lot of my problems with VB.NET is I'm still approaching
it in the same way I've programmed since the late 70's. I've always been
very structured, flow-charted everything, used subroutines, etc. Now I'm
trying to study this new way and I'm getting some terms confused and can
find no clear definition (some even overlap or use two different words for
the same thing, even when they are actually different).

I'm reading a document called "Understanding Interface-based Programming":
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvb600/html/ifacebased.asp.
I'm assuming it's talking about a GUI or form of "user interface" to the
program. But that doesn't seem to be the case. Can someone point me in the
right direction?
 
if you have visual studio installed paste this link into the little help bar
or windows run box; use this if you have it installed, there are more links
at the bottom of the page.

ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/vbcn7/html/vaconInterfacesInVisualBasic70.htm

Here is the contents of the page if you don't have it installed
Interfaces, like classes, define a set of properties, methods, and events.
But unlike classes, interfaces do not provide implementation. They are
implemented by classes, and defined as separate entities from classes.

An interface represents a contract, in that a class that implements an
interface must implement every aspect of that interface exactly as it is
defined.

With interfaces, you can define features as small groups of closely related
members. You can develop enhanced implementations for your interfaces
without jeopardizing existing code, thus minimizing compatibility problems.
You can also add new features at any time by developing additional
interfaces and implementations.

Although interface implementations can evolve, interfaces themselves cannot
be changed once published. Changes to a published interface may break
existing code. If you think of an interface as a contract, it is clear that
both sides of the contract have a role to play. The publisher of an
interface agrees never to change that interface, and the implementer agrees
to implement the interface exactly as it was designed.

Versions of Visual Basic prior to Visual Basic .NET could consume interfaces
but not create them directly. Visual Basic .NET allows you to define true
interfaces using the Interface statement, and to implement interfaces with
an improved version of the Implements keyword.
 
Not trying to rant - just constructive feedback.

I find the documentation difficult as well. Stating the facts without
explaining the facts is the root of the problem.

I really do believe a picture is worth a thousand words. Does msdn
have any?

See confusion statements of "implementation" below.

Forrest



... interfaces do not provide implementation.

Although interface implementations can evolve, ...

< snip >
 
Ricky,

I hear what you are saying. I have been programming for 37 years in the
past 10 years of updating to the "latest" technology the "new kids" at
Microsoft have reassigned the terminology. It isn't really good or bad, it
is just different, but can be confusing.

The use of the term Interface in DOT NET (and other "modern" development
environments) does not describe interaction with the user, but describes a
feature used to insure that a class (module, program, ...) exposes a
predefined set of properties, methods and events.

Because in DOT NET we can create an instance of any .exe or .dll (assembly),
we can look into this assemby and find the classes. Then inside these
classes we can look to see if they support a particular "INTERFACE". Then
we can create an instance of the class and through properties, methods and
events we can interact with the class even though we as a programmer may
have never seen this class.

I implement my applications as "Features" (I use features as a term to
describe such things as Contacts, EMail, Calendar, etc). In my current
application there are over 40 different features which can be developed
independently from each other and can be deployed as separate applications.
(Stay with me here) Then all of these "Features" can be combined into a
single application running under an Outlook Style User Interface. Each of
these "Features" is deployed as an executable (.exe) assembly and supports a
number of standard interfaces required by the Outlook Style iUser Interface.
This allows the Outlook Style User Inteface Application to look into a
directory containing the executable feature assemblies, load each of the
assemblies and determine which "Features" can be added to the Outlook Bar of
the Outlook Style User Interface.

Now if you followed all of that you will see that the Programming Interface
is a way to ensuring a class supports a defined set of properties, methods
and events. And the terminology we have been using for years of "User
Interface" should probably always include both words.

The above is a lot of words to describe what is going on, but this is the
way I see it today.

-Sam Matzen
 
Forrest,
What's confusing about Jared's statement?
Interfaces do not provide implementation, they provide a list of Subs,
Functions, Events, and Properties that a Class or Structure must implement.
(notice "Class or Structure must implement")
When a Class or Structure Implements (via the Implements keyword) an
Interface, that Class or Structure can be said to be that interface's
implementation. A different Class or Structure can also implement the same
Interface. There are now 2 implementations of the interface, as long as they
provide similar behaviors the routine using that interface is non the wiser.

This specific implementation of the interface can evolve. In that the code
itself can change, this is in no way a reflection of the interface itself.

Take IEnumerable for example, this is one of the interfaces For Each uses.
It defines a single member "Function GetEnumerator() As IEnumerator", yet a
significant number of classes implement this Interface each returning a
different specific IEnumerator object. IEnumerator is a the other interface
that For Each uses, it does the actual iteration work... In other words all
classes that support For Each implement IEnumerable returning a different
class that has a specific implementation of IEnumerator for the parent
"collection" class.

Hope this helps
Jay
 
Hal9000,
I agree with you, I find the documentation a little hard to read at
times, but, the information is there. You may have to go back and read,
re-read and read again to get a solid understanding.

The general idea of an interface (as I understand them) is:
They provide a common group of functions and methods to which you must
follow. However, they do not contain any code that does any of the work.

For example, I created a new class called MyFriends; MyFriends "Implements"
or better put, makes available a predefined group of methods/functions of
IEnumerable. These methods/functions are defined in the Interface; so,
again, an interface simply defines the methods/functions that an object
which "Implements" it WILL contain.

The two statements you pointed out don't make sense at first, but, they make
perfect sense when you understand what an interface does.
1:) interfaces do not provide implementation. - No they provide the empty
methods to which you, the developer will provide the logic. Interfaces only
tell you what you MUST at a minimum include.

2:) Although interface implementations can evolve - Yes, you can add to an
"Implementation" of the interface to expose additional functionallity, but,
you cannot change the interface itself. If you did, that object that are
currently implementing the interface will no longer work, they may not have
the same signature, or functions that were once included.

Hope this helps,
Jared

For this example I used a WebForm, but, you can place it in a winodws or
console app just the same just change the Response.Write to
Console.WriteLine.

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim Friends As New MyFriends
'Create a new friends class and fill it with some of your Northwinds
friends

With Friends
.AddFriend("Nancy", "Davolio")
.AddFriend("Andrew", "Fuller")
.AddFriend("Janet", "Leverling")
.AddFriend("Margaret", "Peacock")
.AddFriend("Steven", "Buchanan")
End With
'Create a new instance of an IEnumerator, which is another interface, it
exposes three methods that MUST be implemented by
'The object that I will assign to it.
'Friends.GetEnumerator returns a new FriendEnumerator class that
implements the IEnumerator interface

Dim MyEnumerator As IEnumerator = Friends.GetEnumerator

'Loop through all the items in Friends

While MyEnumerator.MoveNext
'Notice that every time .Current or .MoveNext is called it returns
to the IEnumerator interface to retreive the results.
Dim Person As MyFriend = CType(MyEnumerator.Current, MyFriend)
Response.Write(Person.FirstName & " " & Person.LastName & "<br>")
End While
End Sub


'Place the rest of the code outside the main class definition

Public Class MyFriend
Private mFirstName, mLastName As String
Public Property FirstName() As String
Get
Return Me.mFirstName
End Get
Set(ByVal Value As String)
Me.mFirstName = Value
End Set
End Property
Public Property LastName() As String
Get
Return Me.mLastName
End Get
Set(ByVal Value As String)
Me.mLastName = Value
End Set
End Property
End Class

Public Class MyFriends
Implements IEnumerable
Private m_friends As New ArrayList

Public Sub New()
End Sub

Public Sub AddFriend(ByVal FirstName As String, ByVal LastName As
String)
Dim f As New MyFriend
f.FirstName = FirstName
f.LastName = LastName
Me.m_friends.Add(f)
End Sub

Public Function GetEnumerator() As System.Collections.IEnumerator
Implements System.Collections.IEnumerable.GetEnumerator
Return New FriendEnumerator(m_friends)
End Function

Private Class FriendEnumerator
Implements IEnumerator

Private m_friends As ArrayList
Private m_position As Int32 = -1

Public Sub New(ByVal Friends As ArrayList)
m_friends = Friends
End Sub
' Implementation of IEnumerator
Public ReadOnly Property Current() As Object _
Implements System.Collections.IEnumerator.Current
Get
Return m_friends(m_position)
End Get
End Property
' Implementation of IEnumerator
Public Function MoveNext() As Boolean _
Implements System.Collections.IEnumerator.MoveNext
m_position += 1
If m_position >= m_friends.Count Then
Return False
Else
Return True
End If
End Function
' Implementation of IEnumerator
Public Sub Reset() _
Implements System.Collections.IEnumerator.Reset
m_position = -1
End Sub
End Class
End Class





As far as the statements you mentioned "interfaces do not provide
implementation."
 
Jared said:
if you have visual studio installed paste this link into the little help bar
or windows run box; use this if you have it installed, there are more links
at the bottom of the page.
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/vbcn7/html/vaconInterfacesInV
isualBasic70.htm

OK. Thanks to every one who posted. Each post helped me in some way. I guess
my confusion was I got to the "interface" page from a page describing "Forms
and event handling". I think most would assume "interface" meant the GUI.
They need to come up with discrete words or at least qualify these ideas.
 
Back
Top