Inherits vs Implemets in C#

I guess the difference is obvious - you inherit a class and implement an interface.

If you write in VB.NET, the difference just shines. Your code looks like:

public class MyClass: Inherits ClassX Implements IInterface.

However, as you sure know, in C# things are a bit messier. The code above will look in C# like this:

public class MyClass : ClassX, IInterface.

I was in a number of presentations where the presenter showed a code silimar to the above, and said the class inherits from IInterface. But the highlight of this was in the (great) TechEd in Israel, when a presenter said, when talking about a code similar to the above, that we have here a multiple inheritance.

Why is it that there is no clear distinction between inherits and implements in C#? Is there any rational reason for this, or the architects just count on the developer to know whether he inherits or implements, based on the capital I?


  • yes, any respectable c# developer should know this. is way too wordy.

  • Amen to that. However the whole naming convention for interfaces is there for a reason - so developers will know if it is an interface. I'd have a hard time listening to that presenter after the fact, I mean he may know a little, but if he even *thinks* that multiple inheritance is possible, hes way over misinformed and tredding on just plain "HELLO" mode. Makes me almost wonder if he had any experience at all or was just giving the canned talk.

  • With interfaces named with I this is clear anyway.

  • or....

    IMHO VB is better in this area....

    there are differences between an interface and a base class.... *BIG* ones!

    so say you are having to maintian code someone else wrote.... say they wrote it in C# and were less than stellar at using "I" in interfaces and so on...

    you might not realize at first which case you had .....

    but in VB the two cases are 100% clear, you know on one (or two) lines what you have.

    BTW: I am *NOT* wanting less skills in a dev. just why should we bust our chops on that kind of stuff? I'd rather create a new / better algorithm for something than have to chase down an interface definition....

  • I feel uncomfortable with the assumption that an interface should be distincted from class by the 'I' at the beginning, and that's all.

    I really don't think you can base your architecture on code conventions. Convention, unlike architecture, is subjet to changes. If tomorrow the convention will change, and interfaces no longer will begin with 'I' (as in Java) - what will you do then?

    BTW - the presenter is far from being a newbie. He is a CTO of a large software company in Israel.

  • Matt, multiple inheritance is possible with interfaces. One interface can inherit multiple interfaces.

    interface IA

    interface IB

    interface IC : IA, IB

  • who was the presenter? what talk was this?

  • Christian - I think you used the wrong terms in your post. Multiple Inheritance is not possible with interfaces. Multiple Implementation is what you're looking for. A class can implement multiple classes, while it can inherit only one class.

    The definition of Inheritance is that a class takes all the functionality of its ancestor. Interfaces do not have functionality at all, and therefore you cannot inherit them. Interfaces only define the class, well, interface, and not its inner plumbing, and therefore you Implement it, and not inherit it.

    Roy - I really don't think I should tell the presenter name (although he is a CTO of one of our largest competitors...). I don't think it has anything to do with this discussion. If it is really important to you - send me a mail.

  • Memi, what do you name the inheritance relationship with an interface that has multiple interfaces it derives from? An interface never has an implementation, so this is not implementation inheritance.

    If you have a class that derives from multiple interfaces, of course this is "implements". If you have an interface that derives from multiple interfaces, this is not "implements", you ust "inherit" the members of the base interface.

    interface IA


    void A();


    interface IB


    void B();


    interface IC : IA, IB // this is not an implementation


    void C();


    class X : IC // this is an implementation


    public void A() {}

    public void B() {}

    public void C() {}


  • We can inherit multiple class in interfaces

  • Jeff's comment may be the dumbest thing I've ever read in my life.

  • In C# you can inherit an interface for which the implementation is in a base class. This cannot be done in VB. If the Implements keyword had been used in C#, the below code would not make sense since B does not actually provide the implementation for IFoo but inherits it.

    public class A
    public void DoIt()

    public class B:A,IFoo

    public interface IFoo
    void DoIt();

  • Speaking of inheritance, I would hate to be the guy who inherits Jeff's mountain of spaghetti.

  • Some people have serious personality problems here - too many code gurus are too arrogant.

  • Well, all your syntax in either language (C#/VB) reduces itself down to IL, where you can have multiple implementations, but just once Inheritance. Regardless of use, syntax declaration, or otherwise - you are stuck with this fact if you use .Net.

  • James, why would you need to declare that the derived class implements the interface when it is already done in the base class.
    Does the derived class not inherit the (for lack of better words) decloration of implementation?

  • cptHotKeys: An interface is a definition of enforcement that describes a class's assured functionality. It can also be used to instaniate a type base on interface where you can cast down another type to be able to interact in a pure faction - between the objects with assurance those function signatures exist as well as the base return types. Take a look at WCF and datacontracts VS. implementation methods. You will see the latter interace usages within WCF. The fore usages simply are used for assured, type safe interaction between two types. If you are not using the 'object sender' style observer pattern event args, you can use generics to know the types, thus evaluate with reflection to parse the Interface implemenations. Once verified, you can be assure a cast to ItheInterface will be assured between your implementer are that sender.

    If this doesn't make sense, you suck and Im sorry. I am drunk and am still wondering how this question is still left unanswered.....wtfo, 4chan anyone.

  • Jeff sux alot he needs attention shame too bad he looking in the wrong places anyway . . .thats why u all losers r called or self-proclaimed developers (like jeff) to differentiate btwn class n interface do ur job!

  • When I met my real love((((((

  • Manchester United - Champion!

  • That's it for this article begin to read this blog. Plus, a subscriber:)

  • author, continued in the same spirit

  • How could such a simple topic become a long discussion?

    I agree, in part, with Memi, got his point but in my opinion it´s a bit misguided.

    Conventions may change with time and relying on them is prone to architectural barriers.
    On the other hand, when working on large projects, a problem even worse emerges when conventions are not used. Imagine a long list of files and oyu not knowing wich are classes or interfaces. You would end up needing a set of organization rules, wich aint that different from a naming convention.

    Given that scaleability is gotta be taken seriously even in the smallest of the projects, I vote for naming conventios on C# and think it's way better than the wordy VB.

Comments have been disabled for this content.