First, let's look at Microsoft. There's a pretty good example in the MSDN documentation for the Implements Statement that looks like this (some code omitted to save space):
Public Interface ICustomerInfo
Property customerName() As String
Sub updateCustomerStatus()
End Interface
Public Class customerInfo
Implements ICustomerInfo
Private customerNameValue As String
Public Property CustomerName() As String Implements _
ICustomerInfo.customerName
Get
Return customerNameValue
End Get
Set(ByVal value As String)
customerNameValue = value
End Set
End Property
Public Sub updateCustomerStatus() Implements _
ICustomerInfo.updateCustomerStatus
' more code
End Sub
End Class
Copy their code, throw it into a Windows application with a Button and you've got it. It works.
Public Class Form1
Private Sub TestImplements_Click( ... ) Handles TestImplements.Click
Dim myCustInfo As New customerInfo
myCustInfo.CustomerName = "Larry"
End Sub
Public Interface ICustomerInfo
< ... same as above ... >
End Class
(And it works when you put the Interface both code first and last, to answer Larry's first question.)
But that really doesn't tell you how to do this in the real world (a problem with a lot of Microsoft's documentation) and this is brought out by Larry's second question. In the real world, you want to define interfaces that will still work with different types of objects and then write the implementation code to match the type of object that your code needs.
The thing that is not explained is how to organize your code in files to make this work the way you see it in real systems. Microsoft's code above, for example, only works when everything is in one file. I checked Paul and Harvy Deitel's massive book (1300 pages and very tiny print), and their examples don't actually work either for the same reason. They don't explain how to deal with separate files.
If you move the Interface ICustomerInfo block into a project by itself, you can Build the code with no errors and produce a DLL. But you can't use that DLL even if you add a reference to it into your project. The illustration below shows the code with the error.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
In the real real world, this problem is solved by adding DLL's to the Global Assembly Cache (the GAC). I documented the way this is done in the article, GACUTIL - Sharing your work in the Global Assembly Cache. Once a DLL has been added to the GAC, then it can be referenced.
What if you just want to glue your application together to see how if works without involving the slegehammer approach of adding it to the GAC? Isn't there a way to do this on a purely local level and still use separate files? The answer is "yes". Here's what you have to do.
First, remember that an object must be a Class. (The only other .NET object is the Structure ... a very different kind of object.) So even though the DLL will Build without errors, it still has to be a Class.
And second, the DLL has to be physically copied to the directory structure of the application that uses it. Here's how Dan Clark explains it in the book Object Oriented Programming with VB 2005 (Apress - 1590595769):
"When an assembly is created, it is marked as private. A copy of the assembly must be placed in the same directory or a Bin subdirectory of any client assembly that uses it."
When this is done, you can suddenly see the default namespace for the DLL in the Properties of a project when a reference to the DLL is added. The use of the Visual Studio 2005 dialogs to add References and Namespaces to projects is explained in the article References and Namespaces in VB.NET. The illustration shows the final application which calls the object which implements an Interface when all are in separate files.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
Remember that in this particular application, CustomerInfoApp (the object) references NewDLL (the interface definition) and they're both referenced by WindowsApplication1. The key parts of the file structure are shown in the illustration below:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
And finally, a completed application that instantiates the object is shown. Hopefully, only one question is left now: "Why doesn't Microsoft explain these things?"
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
