Interface Objects and basic object methods.

[rbulph]

Shouldn't interface objects have the basic methods of an object, like GetType, Equals, etc.? For instance, in the following code I have to had quite a bit extra to tell if the two objects are of the same class. Maybe the answer is that I should be using inheritance instead of an interface here, but still, logically it seems surprising that you can't use all the basic methods of an object on an object referenced like this.

 

Public Class Form1

   Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
       Dim p As INameObject
       p = New class1
       Debug.Print(TypeName(p))
       Dim c As INameObject
       c = New class2
       Debug.Print(c.FnGetType Is p.FnGetType)
       '     Debug.Print(c.gettype Is p.gettype)  'Can't say this.

   End Sub
End Class

Public Interface INameObject
   Property Name() As String
   Function FnGetType() As Type

End Interface

Public Class class1
   Implements INameObject

   Private pName As String
   Public Property Name() As String Implements INameObject.Name
       Get
           Return pName
       End Get
       Set(ByVal value As String)
           pName = value
       End Set
   End Property

   Public Function FnGetType() As System.Type Implements INameObject.FnGetType
       Return Me.GetType
   End Function
End Class

Public Class class2
   Implements INameObject
   Private pName As String
   Public Property Name() As String Implements INameObject.Name
       Get
           Return pName
       End Get
       Set(ByVal value As String)
           pName = value
       End Set
   End Property
   Public Function FnGetType() As System.Type Implements INameObject.FnGetType
       Return Me.GetType
   End Function
End Class

[Gill Bates]

You really do not need a method in the interface to return the Type. The GetType method will be part of "class1" and "class2" as it is a method of "object". It is not going to be available through the interface.

 

If you implement the interface explicitly (which you did in your example) then just declare an instance of the instead and then cast it into the interface when you want to access the properties/methods of the interface.

 

If you implement the interface implicitly you can just access the interface properties/methods through the class.

Edited September 29, 2006 by Gill Bates

[rbulph]

You really do not need a method in the interface to return the Type. The GetType method will be part of "class1" and "class2" as it is a method of "object". It is not going to be available through the interface.

 

If you implement the interface explicitly (which you did in your example) then just declare an instance of the instead and then cast it into the interface when you want to access the properties/methods of the interface.

 

If you implement the interface implicitly you can just access the interface properties/methods through the class.

 

Sometimes I may not know what type of objects I have except that they implement INameObject. But I suppose I can always do:

 

 Dim t1 As Type = CType(p, Object).GetType
       Dim t2 As Type = CType(c, Object).GetType
       Debug.Print(t1 Is t2)

 

What's the difference between explicit and implicit implementation of an interface?

[Gill Bates]

With explicit implementation callers into the interface must cast the object into the interface in order to access its properties/methods. With implicit implementation callers into the interface are able to access the properties/methods as if they were part of the class.

 

Example:

interface MyInterface
{
   string Name
   {
       get;
   }
}

interface AnotherInterface
{
   int Age
   {
       get;
   }
}

class MyClass : MyInterface, AnotherInterface
{
   // explicit
   string MyInterface.Name
   {
       get { return "Wow"; }
   }

   // implicit
   public int Age
   {
       get { return 29; }
   }
}

class Program
{
   static void Main(string[] args)
   {
       MyClass m = new MyClass();


       // reference to property of explicit interface implementation
       // this is the only way you can "see" the "Name" property
       // of the interface
       Console.WriteLine(     ((MyInterface)m).Name     );

       // reference to property of implicit interface implementation
       Console.WriteLine(      m.Age     );

       Console.ReadLine();
   }
}

[rbulph]

I don't think VB has that. I would have said that implementation in VB is all implicit, contrary to what you said in your first reply, because there is no need to cast the object to the interface in order to access the implementing methods.

[Gill Bates]

Yeah, looks like you're right. VB.NET does not have it.

[PlausiblyDamp]

Sometimes I may not know what type of objects I have except that they implement INameObject. But I suppose I can always do:

That is kind of the point of interfaces - you write code that works with the defined interface without needing to know the specifics of the implementation.

[snarfblam]

That is kind of the point of interfaces - you write code that works with the defined interface without needing to know the specifics of the implementation.

In other words, the type used should reflect the intended use. If you are using an IList, you shouldn't need to know its System.Type, all you need to know is that it implements a list service. Interfaces are there so you can kinda forget about types.

 

If you need to test the System.Type of an object, you can use the TypeOf...Is... clause:

Dim List1 As IList = New List(of Integer)
If(TypeOf List1 Is List(of Integer)) Then _
   MessageBox.Show("List1 is a list of integers.")

or you can cast to a System.Object to treat the item as an object.

 

As to Implicit/Explicit interface implementations, VB has no direct analogy. In fact, VB is much, much more flexible in this manner. VB can implemenet each member (using "C# terminology") "implicitly" (declare the method as public), "explicitly" (declare the method as private) or implement the member using a different name than the interface's declared name for that method.

Edited October 1, 2006 by snarfblam