none
interface vs abstract class RRS feed

  • Question

  • I have found the below in the MSDN

    "If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface. "

    Can we have an example so that we can see the version becomes different after changing the interface and for abstract class running well?

    Many Thanks.....
    Friday, February 26, 2010 11:34 AM

Answers

  • Let's say you have an abstract class named "Bird", which implements the public method "Fly()" and you have several other classes like "Duck" and "Eagle" which inherit from "Bird". So far so good, you could do the same with an interface.

    However, if sometime later you find the need to add a new method "Land()", you're free to do it in the abstract class. But, if you try to do the same thing with an interface, every class implementing that interface will stop compiling because they're not implementing the full interface. That could raise a severe problem if you have many many classes implementing that interface, or if you have third party clients consuming the interface.

    -- Blog: http://geeklyeverafter.blogspot.com/
    Friday, February 26, 2010 3:59 PM

All replies

  • Let's say you have an abstract class named "Bird", which implements the public method "Fly()" and you have several other classes like "Duck" and "Eagle" which inherit from "Bird". So far so good, you could do the same with an interface.

    However, if sometime later you find the need to add a new method "Land()", you're free to do it in the abstract class. But, if you try to do the same thing with an interface, every class implementing that interface will stop compiling because they're not implementing the full interface. That could raise a severe problem if you have many many classes implementing that interface, or if you have third party clients consuming the interface.

    -- Blog: http://geeklyeverafter.blogspot.com/
    Friday, February 26, 2010 3:59 PM
  • if the method Land() is abstract, then it will give an error message as it gives error



    Error    1    'ConsoleApplication2.plant' does not implement inherited abstract member 'ConsoleApplication2.organism.Land()'    C:\Documents and Settings\DEV\My Documents\Visual Studio 2008\Projects\ConsoleApplication2\ConsoleApplication2\Program.cs    37    11    ConsoleApplication2


    However, if we put a concrete method inside the abstract class it will work. But, is this what is meant in the original statement which i posted before.




    Sunday, February 28, 2010 9:13 AM
  • > But, is this what is meant in the original statement which i posted before.
    Yes. You can add non-abstract methods to abstract classes and have existing clients continue to work, you can't however, add abstract methods (in the same vein as you can't add methods to interfaces).

    In the Framework, we usually add a virtual method with default behavior that new clients (or recompiled clients) can choose to override if they so choose.

    Base Class Library Team (BCL) | My Blog: http://davesbox.com
    Monday, March 1, 2010 6:04 PM
    Moderator
  • So, due to this elegant behaviour of virtual method (although you have the concrete body yet you can overrride it). This is what is versioning being refered?
    Tuesday, March 2, 2010 5:47 AM
  • Yes, I think the "multiple versions" in that sentence means exactly that. Because if you do intend to add a concrete method to an already existing class, you're supplying it with a new behavior, so you're efectively creating a new version of that class. For instance, TimeSpan class (it's not the perfect example for this discussion, because it isn't an abstract class, but it serves the purpose of this example) has been enhanced with a few new features and methods in .NET4, so you can say that you do have a different TimeSpan in .NET3.5 and in .NET4. A new version of TimeSpan.
    -- Blog: http://geeklyeverafter.blogspot.com/
    Tuesday, March 2, 2010 9:36 AM