none
Interface polymorphism... why doesn't this work? RRS feed

  • Question

  • I'm having a super-darrr-tarded moment.  

    I can't figure out why this doesn't work.

    Polymorphism is supposed to automatically call the most-derived implementation of something, yet I cannot write an Interface in such a way that the Interface calls the proper derived implementation, I get errors all over the place if I try to do this.  Derived classes are ONLY allowed to implement the interface method (function in this case), by declaring the return type as the base type, rather than the type doing the implementing, which is ridiculous.

    This seems like polymorphism 101, and I'm totally dumbfounded as to why this doesn't work, when it's obviously the behavior one would desire.

    Say you have the following...

    Interface IPet
    
       Function Clone As Pet
    
    
    Public Class Pet
    
       Implements IPet
    
        Must Override Function Clone As Pet
    
    
    Public Class Tiger
    
        Inherits Pet
    
        Overrides Function Clone As Tiger  (impossible, cannot use Tiger as return type, but polymorphism should demand this behavior be fine)
    
    
    Public Class Monkey
    
        Inherits Pet
    
        Overrides Function Clone As Monkey   (impossible, cannot use Monkey as return type, but polymorphism should demand this behavior be fine)



    WCF should be renamed WTF


    Tuesday, May 22, 2012 3:38 AM

Answers

  • An interface defines a specific behavior.  "For any instance of an IPet, calling Clone() will produce an instance of a Pet".  (BTW, shouldn't clone return an IPet?)

    So the rule is you will return a Pet, not a Tiger or Monkey.  The compiler is enforcing this rule. 

    All Tigers are Pets but not all Pets are Tigers.  When it's your own code you can make lots of unwritten (and thus hard to maintain) rules about what kinds of IPets get passed around.  Consider, however, a public function being passed an IPet implemented by someone else.  The only thing you can rely on is that it has a method called Clone which returns a Pet. 

    You shouldn't be treating it like a Monkey or a Tiger because it could very well be an Iguana.


    This signature unintentionally left blank.

    Tuesday, May 22, 2012 10:59 AM

All replies

  • An interface defines a specific behavior.  "For any instance of an IPet, calling Clone() will produce an instance of a Pet".  (BTW, shouldn't clone return an IPet?)

    So the rule is you will return a Pet, not a Tiger or Monkey.  The compiler is enforcing this rule. 

    All Tigers are Pets but not all Pets are Tigers.  When it's your own code you can make lots of unwritten (and thus hard to maintain) rules about what kinds of IPets get passed around.  Consider, however, a public function being passed an IPet implemented by someone else.  The only thing you can rely on is that it has a method called Clone which returns a Pet. 

    You shouldn't be treating it like a Monkey or a Tiger because it could very well be an Iguana.


    This signature unintentionally left blank.

    Tuesday, May 22, 2012 10:59 AM
  • Thanks.  I guess I had a powerful brain fart that knocked out my reasoning for a while.  You're right, it should return an IPet.  Reading your perspective lifted the fog.

    WCF should be renamed WTF

    Wednesday, May 23, 2012 5:19 AM