Results 1 to 5 of 5

Thread: implementation and interface inheritance?

  1. #1

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Location
    Delhi
    Posts
    1

    implementation and interface inheritance?

    Hello Friends... I am Start Learning .Net and i want to know What is implementation and interface inheritance?

  2. #2
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,274

    Re: implementation and interface inheritance?

    That information is available in many, many places around the web and they aren't hard to find with a web search. There's really no need for us to repeat it yet again here. If there is something specific that you don't understand about what you've read elsewhere then you should definitely ask about that specifically and we can help with that.

  3. #3
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: implementation and interface inheritance?

    "Interface inheritance" means your type is making a promise that it has certain properties and methods. It doesn't make guarantees about how they behave, though generally when we write an interface we define some behavior. That an interface can't enforce behavior is a weakness of this style of inheritance. That you can inherit multiple interfaces is a strength of this behavior. (In future C# versions you'll be able to inherit behavior via interfaces, it is not clear if VB will have this feature.)

    "Implementation inheritance" means several things. One is logical: you are asserting your type is a specialization of the type it inherits. The other is mechanical: your type has every member of the base class, and can access any public or protected members. You may override any virtual types on the base type to further specialize the behavior. Since you inherit behavior, nonvirtual implementation inheritance lets base types guarantee behavior. One serious limitation of implementation inheritance is you can only inherit one type's implementation.

    Understanding the difference between these two is key to modern software engineering. Your classroom and textbooks are going to focus on implementation inheritance, because they are mimicking what was written in the 90s. Most modern software engineers agree interface inheritance is more flexible and useful.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  4. #4
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,274

    Re: implementation and interface inheritance?

    @Sitten Spynne, it seems to me that you have interpreted those terms differently to me, so I thought that it was worth clarifying. I also think that you made mistake and typed "Implementation inheritance" when you meant "Interface implementation".

    When it comes to inheritance, to my mind, a class can inherit a class and an interface can inherit an interface but a class cannot inherit and interface. A class can only implement an interface. I thought that this:
    What is implementation and interface inheritance?
    was basically asking what is a class implementing an interface and an interface extending another interface. Maybe I was wrong or maybe I was right and you interpreted it differently.

  5. #5
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: implementation and interface inheritance?

    Quote Originally Posted by jmcilhinney View Post
    @Sitten Spynne, it seems to me that you have interpreted those terms differently to me, so I thought that it was worth clarifying. I also think that you made mistake and typed "Implementation inheritance" when you meant "Interface implementation".

    When it comes to inheritance, to my mind, a class can inherit a class and an interface can inherit an interface but a class cannot inherit and interface. A class can only implement an interface. I thought that this:

    was basically asking what is a class implementing an interface and an interface extending another interface. Maybe I was wrong or maybe I was right and you interpreted it differently.
    This is kind of sticky and you aren't wrong, it all comes down to how you decide to define certain terms. Within your definitions, what you say is correct. If we mean "inheritance" to imply that some code is being passed down and (at least potentially) participating in polymorphism, then an interface certainly can't participate in it.

    I find most people who talk about architecture are polyglots and in that context the definitions of "class" and "interface" are a little more fuzzy because they don't tend to talk about specific languages. In those contexts, they tend to just use the word "interface" when discussing inheritance concepts. They'd argue that, in VB, "a class" is a special kind of Interface that can provide implementations of its members and has more restrictive rules for inheritance. (I think most devs who don't look to the software engineering community tend to invert this and see Interfaces as less useful classes.)

    The term "interface inheritance" is kind of more coded to mean "a composition-heavy approach with Dependency Injection". Interfaces are meant to define behaviors more than hierarchical relationships. So in this context, we wouldn't make a Fish base class with a Swim() method for a zoo simulator, because we also have a Duck class that is a Bird but needs to Swim(). So we'd make an ICanSwim interface with a Swim() method. If it turns out the code for swimming is common, we'd create some SwimBehavior type that implements it, and both Fish and Duck would delegate to that type.

    So if I have an ICanSwim, it could be a Goldfish or a Duck or a Dolphin, but I don't care, I just know it can Swim(). And what I get when I call Swim() is polymorphic, but it could still be true that all Fish share the same Swim() implementation, and some Fish might choose to replace that implementation with something else. And I can have Duck be a Bird that can Swim() and Fly(), but Penguin be a Bird that can Swim() but not fly, etc. Omission is not a thing class inheritance does well, so to handle the same cases I'd need extra layers like "FlightlessBird" in my hierarchy, and class inheritance still doesn't provide a good solution for things like FlyingFish or Platypus.

    Thus, "interface inheritance". It takes a little more work, but can do everything "class inheritance" does, without the pesky "multiple inheritance is not allowed" issue. So I can make a Platypus, which is a Mammal that has venom, can swim, and lays eggs, without completely maiming my inheritance hierarchy.

    It could be I know too much, and your definition's more sufficient for this homework problem. But I feel like what I said about "books favor class inheritance and this is obsolete thinking" is very true.

    This is all going to get weird in C# soon, because "interfaces with implementations" are going to be a feature. I don't think it's on the VB roadmap.
    Last edited by Sitten Spynne; Jan 26th, 2018 at 11:39 AM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width