Printable View
Hi Guys,
I'm trying to learn more about .net programing but any of the information I have is academic in nature. I'm learning about interfaces and would just like to know if anyone has used them in a practical sense. I'm hoping this helps me understand their purpose better.
Thanks!
Found a great example, thanks:
http://www.vbforums.com/showthread.php?t=555384
Hmmm, perhaps an example:
I'm going to be working on a program that will have modules than need to be added to the program at a later date. Heck, they won't even be designed at the time the main program comes out. So how will the main program know what to do with these add-in modules? One alternative would be to put an instance of a specific class into each module, and have the main program create an instance of this class and work with that. But what would that class look like? Since a class definition would be relatively static, a method that returned "My Menu Item" would have to return the exact same thing for every module. The only way to make that work would be if the module contained a bunch of private things that populated the properties of the class, which would be a horrible design from an OO perspective.
Instead, each module will have a class that implements the same interface. Therefore module1 can have class Mod1Class that implements the interface, while module2 can have class Mod2Class that implments the interface. Mod2Class can be entirely different from Mod1Class. It can do different things, contain different properties, different data, whatever. The interface is a contract saying, effectively "whatever else I am doing, however I am built, I will AT LEAST have these features, and implement these methods."
Therefore, since Mod1Class and Mod2Class both implement the interface, then they have to implement the same things. Suppose the interface has these two methods:
This means that those two methods will have to exist in Mod1Class and Mod2Class. If that was all there was, this really wouldn't help very much. The main application would now know that if it created an instance of ModXClass, it could count on those two methods being there, but the main application wouldn't know whether to create an instance of Mod1Class or Mod2Class. That would depend on which module the application was looking at, which, ideally, it shouldn't care about.Code:Public Interface IModuleMethods
Public Function MyMenuItem() as String
Public Sub MyMenuClickMethod()
End Interface
The solution to this is that any class that implements an interface can be cast into an instance of that interface. Therefore, the main application doesn't need to know what type of class it is getting. It will be getting an instance of IModuleMethods, which could actually be either a Mod1Class or a Mod2Class, but the main app neither knows, nor cares. All the main app knows is that it received an IModuleMethods, and it knows the methods in that interface, so it can call those methods. It can call the first method to get the menu item string that needs to be added to the menu, and when the user clicks on that menu item, it can call the MyMenuClickMethod, and let the class handle it as it wants to.
Therefore, the interface is just a means of putting a common mask on a whole bunch of different animals. Each animal can do what it wants behind the mask, but the mask looks the same, and behaves the same, to the process observing it. Better yet, as far as the observer is concerned, it is getting an instance of the mask, and doesn't care what animal is behind it.
Hope that helps.
You beat me to an answer for your own question:ehh:
I know ha ha, I have been activly searching although your example is pretty well thought out too very informative, infact it gives me an idea on how to extend an existing application!
Found? haha you mean I sent you it :PQuote:
Originally Posted by DeanMc
PS Thanks for the example Shaggy, that helps clarify things for me as well :)
Shhhh, no one can no we MSN each other!!!!
ok, your secret is safe with me. lover.
Ha ha.... (I don't know him :P)