Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Visual Basic
  4. Implementing an interface (quandry)...

Implementing an interface (quandry)...

Scheduled Pinned Locked Moved Visual Basic
regexquestion
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Ray Cassick
    wrote on last edited by
    #1

    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 Interface

    Now, I want to impliment it from two different classes as such

    Public Class One
    Implements ILogEntry

    Public Sub AddEntry(entryText as String) Implements ILogEntry.AddEntry
    . . .
    End Sub

    End Class

    Public Class Two
    Implements ILogEntry

    Public Sub AddEntry(varName as String, varValue As String) Implements ILogEntry.AddEntry
    . . .
    End Sub

    End 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."


    J 1 Reply Last reply
    0
    • R Ray Cassick

      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 Interface

      Now, I want to impliment it from two different classes as such

      Public Class One
      Implements ILogEntry

      Public Sub AddEntry(entryText as String) Implements ILogEntry.AddEntry
      . . .
      End Sub

      End Class

      Public Class Two
      Implements ILogEntry

      Public Sub AddEntry(varName as String, varValue As String) Implements ILogEntry.AddEntry
      . . .
      End Sub

      End 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."


      J Offline
      J Offline
      Jim Stewart
      wrote on last edited by
      #2

      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 an AddEntry 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 a GetEnumerator method (which returns an object that implements the IEnumerator 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 Interface

      So long as the method signature matches, the compiler won't complain.

      α.γεεκ

      Fortune passes everywhere.
      Duke Leto Atreides

      R 1 Reply Last reply
      0
      • J Jim Stewart

        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 an AddEntry 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 a GetEnumerator method (which returns an object that implements the IEnumerator 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 Interface

        So long as the method signature matches, the compiler won't complain.

        α.γεεκ

        Fortune passes everywhere.
        Duke Leto Atreides

        R Offline
        R Offline
        Ray Cassick
        wrote on last edited by
        #3

        I 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."


        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups