Interfaces, Implements and Implements...

  • Thread starter Thread starter Klaus Löffelmann
  • Start date Start date
K

Klaus Löffelmann

Hello,



why is it necessary to implement every procedure of an interface by
assigning it manually with another "implements" to the corresponding
procedure of the class, which actually implements the interface. Isn't the
name of the procedure good enough for assigning it unambiguously? I mean,
it's enough with simply deriving one class from another one?



My first thought was, it has something to do with the case sensitivity,
which would be taken into account at least "behind" the Implements-keyword.
But that's not the case (literally ;-).



I've been doing C# until know, so I apologize in advance, if this is a
stupid question.




Thanks for giving it a thought



Klaus
 
Klaus Löffelmann said:
why is it necessary to implement every procedure of an interface
by assigning it manually with another "implements" to the
corresponding procedure of the class, which actually implements the
interface. Isn't the name of the procedure good enough for assigning
it unambiguously?
Click to expand...

No, it is not enough. Maybe the class already has a method with the same
name, but the method has a different signature.
 
why is it necessary to implement every procedure of an interface by
assigning it manually with another "implements" to the corresponding
procedure of the class, which actually implements the interface. Isn't the
name of the procedure good enough for assigning it unambiguously?
Click to expand...

In C#, yes. It's just one of the CLR things that VB.NET exposes but C#
does not. It's merely a feature of the language -- you can tell the CLR
which method implements an interface method without having to name it
exactly the same as the interface.
 
* "Klaus Löffelmann said:
why is it necessary to implement every procedure of an interface by
assigning it manually with another "implements" to the corresponding
procedure of the class, which actually implements the interface. Isn't the
name of the procedure good enough for assigning it unambiguously? I mean,
it's enough with simply deriving one class from another one?
Click to expand...

That's how it is done in C#. VB.NET is more flexible, you can change
the name of a procedure which implements a procedure defined in the
interface. And the procedure can implement more than one method of the
base class, if necessary.
 
No, it is not enough. Maybe the class already has a method with the same
name, but the method has a different signature.
Click to expand...

And besides that it makes for good programming practise. If you
develop a class that implements an interface and the implements
keyword is ommitted
and then i end up working with that class or some derivative of it,
it's going to take me longer to get to get grips with that classes
architecture.

I like the implements keyword, it makes things explicitly clear. And
the point made earlier about being able to use a different name for
the member that implments the implementable member is huge.

I think what you're suggesting would greatly limit the flexibility of
the language and certainly require more work upfront to ensure that
nothing your building has naming conflicts with any of its imported
interfaces.

Richard
 
Back
Top