Still not getting the interfaces, Please help.

[VBHuguenot]

I have read 3 books on interfaces. Studied 6 web sites on interfaces. Read posts in this forum on interfaces and I am still not getting it. I am a very intelligent person, but for some reason interfaces to me are like ...well?... Interfaces.

Here is an example to get someone started to build on for my feeble interfaced mind. Thanks....

Public class Class2
MessageBox.Show("Class 1 Time is: " & DateTime.Now)
End Class

Public class Class2
MessageBox.Show("Class 2 Time is: " & DateTime.Now)
End Class

Public class Class3
Implements MyInterface
 Public Sub tellTime() Implements MyInterface.tellTime

    End Sub
End Class

Public Interface MyInterface
sub tellTime()
End Interface

OK, so here is what I totally don't get. What is the use of using the "MyInterface" in class three? I can type in code within the "tellTime" method in class3. But lets say I need the same thing in class 2? Then I would have to redundantly type the same code in class 2? so it would look like this:

Public class Class2
Implements MyInterface
 Public Sub tellTime() Implements MyInterface.tellTime
        ....
    End Sub
End Class

Which in turn would look exactly like class 3:

Public class Class2
Implements MyInterface
 Public Sub tellTime() Implements MyInterface.tellTime
        ....
    End Sub
End Class

So why not just do this?

Public class Class2
 Public Sub tellTime()
        ....
    End Sub
End Class

Public class Class3
 Public Sub tellTime()
        ....
    End Sub
End Class

I just dont get it? I hear that you use it for multiple inheritance, but I dont see the inheriting anywhere? Please help I am running out of money purchasing books!!!

 

[JohnH]

If you need two or more different classes to do the same while not inheriting the same base class you use interface. The difference from inheritance is you can only inherit one class, but you can implement as many interfaces as you want. With inheritance you can inherit the base code without overriding it, so you don't write any more code. With interfaces you have to provide an implementation, you have to write the code that carries out everything the interface is defined to do. When binding a class to an interface you sign a contract to fulfill this simplified definition of an object, user will only rely on and relate to the interface and not your class definition.

Think rationally of the word "interface", and compare it to the use in the "real" world, maybe you will get some clues.

For each lock there is a key, the key is the interface, a lock and a key can be many different both physical and abstract things, but if something is locked and you want to unlock it you have to use the key. Interface is an abstraction.

Through an interface you are using something as a simple object when there is more to it, and often several ways of using it depending who you are. For you the cash machine is where you receive money, for the bankier where money is given, for the central computer a point of service where transactions are made, for the programmer a computer that interacts with a mechanical device and networks, for the technician a piece of metal that needs oil and service parts. It's one big machine object that works in sync and provide different interfaces, none of these need to know everything about it, they just use it through each their own interface. Interface is a point of view.

This viewpoint functionality also provide a simple mechanism to handle multiple different objects as if they were the same. For example you want to sort an array of something, in simple cases you just call the Sort method, you can do this because for primitive types there is already defined the IComparable interface. Sorting Integers or Strings is all the same, just call Array.Sort and it will compare all the items. You can write any class, create an array of this class items, then call Sort and it will fail because this method don't know how to treat your objects. Now implement IComparable interface where you have define how items of your class compares to one another in the CompareTo method, suddenly Array.Sort works, all it has to do is to cast you class instance as an IComparable type and use the CompareTo method to know how any item relates to another. So you see it doesn't matter for the Sort method what type of object your is and what else it does and contains, all it wants is to use it as an comparable object and make the comparisons necessary to reorder the items in the array. If the class implement the IComparable interface the sorter know it has the CompareTo method to use, if not it can't sort it.

Hopefully some of these thoughts around the subject makes sense to you.

Here is one practical pseudo code example:

interface IOne:
sub Speak

class A: implements IOne
sub Amethod implements IOne.Speak

class B: implements IOne
sub Bmethod implements IOne.Speak

dim x as IOne
x = new A
x.Speak() 'Amethod is called
x = new B
x.Speak() 'Bmethod is called

The x variable is type IOne, different class instances that implements this interface can be assigned. It doesn't matter here what method implementation is actually called, it is the interface Speak method that is of interest. Other places in code the A or B class types of course have their own uses, but at certain places they only need to be a IOne and Speak.

An iteresting variation of use of interfaces is compiling and deployment of assemblies, this could be addins that are added or upgraded without need to upgrade the main application that only need to use the external assemblies through the interface. This could also be remoting where the implementing assembly can be changed and don't have to be deployed to clients that already only use the interface, so different "real" objects can be transmitted while the receiver is unchanged.

 

[Administrator]

I think a simpler answer is that an Interface is a TEMPLATE of code. For example, you have forms that you want to do the same thing, i.e. in my app I have an IGrid interface as every form that I use that has a Grid control should have certain methods such as SaveLayout, RestoreLayout, ResetLayout, etc. So I create a "template" or "interface" that has:

Sub SaveLayout
Sub RestoreLayout
Sub ResetLayout

Then when I create a new Winform that has a grid, I add "Implements IGrid" after the class declaration and the method signatures will be created for me that I know I need to populate to keep all my grid forms standardized.

It's really very simple, don't make it harder than it needs to be. Again, an interface is just a "template" of code you want to use among all forms that Implement the Interface definition.

 

[VBHuguenot]

Ahhhhh I see. So basically it doesn't add code. its just a template so you don't forget what that class HAS to have in it in order to function.

so if class1 and class2 both implement an interface IMyInterface that has a sub called "MySub" that should have x lines of code in it and you need to have both Class1 and Class2 have this sub, BUT since you need to have multiple inheritance you can not inherit class1 from class2, ....

Then you have to have to sort of cut and paste the x lines of code in to both class1 and class2 and also for every sub that is listed in the IMyInterface interface?

Does this sound right?
For example

Public Interface IMyInterface
Sub MySub()
End Interface

Public class class1 
Sub MySub() Implements IMyInterface.MySub
        Class1.MySub Code here
End sub
End Class

Public class class2
Sub MySub() Implements IMyInterface.MySub
        Class2.MySub Code COPIED EXACTLY AS CLASS1.MYSUB CODE
End sub

End Class

 

[Administrator]

Yep, that's right! It doesn't actually put code in the methods, it just adds the method signatures so you can code them as needed. Give it a try, just create a simple interface, i.e.

Public Interface IVBTester

Sub Method1
Sub Method2

End Interface

Now create two classes and in each class add "Implements IVBTester" and press enter. You'll see it add the methods for you and then you can code as needed.

 

[VBHuguenot]

Great. Thanks Neal for all your help.