Implementing an interface (quandry)...
-
I am having a very difficult time undersatnding the usefullness of implementing an interface here. I tried to define one interface that has a AddEntry method:
Public Interface ILogEntry
Public AddEntry()
.
.
.
End InterfaceNow, I want to impliment it from two different classes as such
Public Class One
Implements ILogEntryPublic Sub AddEntry(entryText as String) Implements ILogEntry.AddEntry
. . .
End SubEnd Class
Public Class Two
Implements ILogEntryPublic Sub AddEntry(varName as String, varValue As String) Implements ILogEntry.AddEntry
. . .
End SubEnd Class
...but I can't seem to get it because the method signatures in my class implementations don't match the actual use in each class. What the heck is the use of useing an interface if it ties me to a specific method signature? I don't want to define the types and method signatures of the intrerface, just the actual methods that need to be implemented. Am I wrong in thinking this or should I be using an abstract base class instead?
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."
-
I am having a very difficult time undersatnding the usefullness of implementing an interface here. I tried to define one interface that has a AddEntry method:
Public Interface ILogEntry
Public AddEntry()
.
.
.
End InterfaceNow, I want to impliment it from two different classes as such
Public Class One
Implements ILogEntryPublic Sub AddEntry(entryText as String) Implements ILogEntry.AddEntry
. . .
End SubEnd Class
Public Class Two
Implements ILogEntryPublic Sub AddEntry(varName as String, varValue As String) Implements ILogEntry.AddEntry
. . .
End SubEnd Class
...but I can't seem to get it because the method signatures in my class implementations don't match the actual use in each class. What the heck is the use of useing an interface if it ties me to a specific method signature? I don't want to define the types and method signatures of the intrerface, just the actual methods that need to be implemented. Am I wrong in thinking this or should I be using an abstract base class instead?
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."
The usefulness of interfaces is very similar to abstract base classes. The purpose of an interface is as a contract to consumer objects that a particular method or property (or event for that matter) will be present - including its signature. You want consumer objects to know that an object implementing the
ILogEntry
interface will have anAddEntry
method (or several overloaded versions of it). With an abstract base class, this concept is no different. I usually only use the abstract base class when there is code common to the derived classes and I want to eliminate duplication. However, due to being limited to single inheritance, the interface becomes again useful. Consider some of the included interfaces with the framework:IEnumerable
promises that there is aGetEnumerator
method (which returns an object that implements theIEnumerator
interface) and nothing more. But in those instances where one wishes to enumerate a collection, this is what is required and expected. As to your particular problem, it appears that you have two method signatures - and your interface supplies neither. This is what you need for this example:Public Interface ILogEntry
Public AddEntry(varOne as String)
Public AddEntry(varOne as String, varTwo as String)
.
.
.
End InterfaceSo long as the method signature matches, the compiler won't complain.
α.γεεκ
Fortune passes everywhere.
Duke Leto Atreides -
The usefulness of interfaces is very similar to abstract base classes. The purpose of an interface is as a contract to consumer objects that a particular method or property (or event for that matter) will be present - including its signature. You want consumer objects to know that an object implementing the
ILogEntry
interface will have anAddEntry
method (or several overloaded versions of it). With an abstract base class, this concept is no different. I usually only use the abstract base class when there is code common to the derived classes and I want to eliminate duplication. However, due to being limited to single inheritance, the interface becomes again useful. Consider some of the included interfaces with the framework:IEnumerable
promises that there is aGetEnumerator
method (which returns an object that implements theIEnumerator
interface) and nothing more. But in those instances where one wishes to enumerate a collection, this is what is required and expected. As to your particular problem, it appears that you have two method signatures - and your interface supplies neither. This is what you need for this example:Public Interface ILogEntry
Public AddEntry(varOne as String)
Public AddEntry(varOne as String, varTwo as String)
.
.
.
End InterfaceSo long as the method signature matches, the compiler won't complain.
α.γεεκ
Fortune passes everywhere.
Duke Leto AtreidesI had tried (at least I thought that I had) to to that was when I tried to implement the interface I looked like I was forced to impliment BOTH the AddEntry methods in my class. I think my problem was that NONE of the parameters to the methods matched in my case. I was trying to use:
AddEntry(entryText As String)
AddEntry(varName As String, varValue As String)Perhaps if I used the naming that you example did where at least one of the vars matched things would have been better? I actualy am testing a version that uses an abstract base class now and it seems to be working well. I actually found some implimentation that was common so it ended up helping in reducing code duplication as well.
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things."