none
When to use Interface & When to use Abstract Class

    Question

  • Hi Guys,

      Its me again. But I have not a new question , a very old one :

      When Should I use Interface & When Should I use Abstract Class.

      Remember I have not asked 'What is the difference between the two'....


     Waiting for some really really good answer.
    zeeshan [ visit my forum: www.code4project.com ] [visit my blog: www.geekswithblogs.net/zeeshanjan]
    Wednesday, January 13, 2010 12:31 PM

Answers

  • Well Guys,

      Thank you for your replies , but I am sorry to say that I am not yet satisfied or I do not yet have a senario where I could say that 'In this senario abstract class must be used and interface won't work or In this senario Interface must be used and abstract class won't work'.

     Well my question is 'When to use Abstract class and when to use interface'?

    Can anyone explain me by giving a typical senario considering an application and explain the answer.
    Sure here is one I use.

    When using a Factory Pattern always return an Interface while the objects underneath the interface adhere to an abstract. Why?

    1. Interfaces supply a contract of work . What will be done . The consumer doesn't care about the implementation, i.e. the guts of the code or the actual object being used.
    2. Since the user doesn't care about what actual object or class is being used. Putting in or replacing an object has no consequence on the consumer. No recompiles nothing. Just give them a new factory.
    The abstract is used to enforce business operations on a derived class or give base functionality which can be overridden. It is not targetted for end use (per-se), only to require that certain operations exist on a derived.

    I would use abstract to make the model /paradigm of what a derived class should do per business logic, and have that derived class adhere to an interface so consumers can use the class to target the actual end data logic goals.

    HTH
    William Wegerson (www.OmegaCoder.Com )
    • Edited by OmegaManMVP, Moderator Thursday, January 14, 2010 2:42 PM added per-se or it would have been questioned....
    • Marked as answer by Zeeshan Jan Saturday, January 16, 2010 3:48 AM
    Thursday, January 14, 2010 2:41 PM

All replies

  • Hi,

    this is a good article for u : http://www.sap-img.com/java/when-we-go-for-abstract-and-interface.htm

    Hope this helps,

    Mathieu
    Mathieu Francesch Sharplog Engineering
    Wednesday, January 13, 2010 1:09 PM
  • Take a look on guidelines provided by Microsoft:

    http://msdn.microsoft.com/en-us/library/dybz98h0(VS.71).aspx
    Wednesday, January 13, 2010 1:29 PM
  • If your abstract class has not executable code, declare it as an interface, elsewhere keep it as an abstract class.
    With best regards, Yasser Zamani
    Wednesday, January 13, 2010 8:38 PM
  • They each have an advantage their pros and cons. 
    They both allow you to force implementation to be defined in consuming classes.

    Interfaces
    -a type can implement multiple interfaces.
    -changes to the interface will ripple across all implementing classes.
    -the consumer has more flexibility in how the implementing class is constructed.

    Abstract Classes
    -a type can inherit only one class at a time, abstract or not.
    -many types of changes to the abstract class do not require changes to all implementing classes.
    -abstract classes can impose some limitations on the inheriting class because of inheritance.

    I have feel into a habit of defining a interfaces and then implementing them on an abstract class.  This gives me the best of both worlds.  If I change the interface, then I only need to change my abstract class.  I have also found that abstract classes can make for some efficient little object factories for inheriting classes.  This same behavior can also restrict what inheriting classes can and cannot define in their own constructors.

    Mark the best replies as answers. "Fooling computers since 1971."
    • Proposed as answer by JohnGrove Wednesday, January 13, 2010 10:57 PM
    Wednesday, January 13, 2010 9:15 PM
  • If your abstract class has not executable code, declare it as an interface, elsewhere keep it as an abstract class.
    With best regards, Yasser Zamani


    Food for thought.
    Calling abstract and/or virtual methods in the the constructor of the abstract class creates some rather interesting possibilities.

    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, January 13, 2010 9:17 PM
  • If your abstract class has not executable code, declare it as an interface, elsewhere keep it as an abstract class.
    With best regards, Yasser Zamani


    Food for thought.
    Calling abstract and/or virtual methods in the the constructor of the abstract class creates some rather interesting possibilities.

    Mark the best replies as answers. "Fooling computers since 1971."

    Yes, you are right,
    If we call something in the constructor of the abstract class then the abstract class contains some executable and we can't declare it as an interface as i told.
    I tried to say when to choose interface and when abstract class.
    If target class dosen't need executable code we declare it as an interface elsewhere as an abstract class.
    Thanks.
    With best regards, Yasser Zamani
    Wednesday, January 13, 2010 9:26 PM
  • Because of the way that C# builds up object vtables - it is not recommended that virtual methods be called from a constructor.  It can lead to errors due to uninitialized values.



    Tom Shelton
    Wednesday, January 13, 2010 9:43 PM
  • Interfaces are for Polymorphism.  It is a contract to define what the callee looks like. 
    Abstract classes are for removing duplication and implementing behavior. 
     

    We've found throughout the years that if we start with inheritance, too often we wind up with tightly coupled code and hacked classes, because its easier to go into the base class and make all the methods virtual than it is to go thru the rest of the app and change all the coupled code to an interface. 

    This thinking has helped us focus on composition-delegation, and has led to less issues when we need to break the inheritance chain.

    And you can specify inheritance in interfaces:
    public interface IMoves
    { void Move(); } public interface IPet : IMoves
    { void MakeNoise(int val); }
    public class Dog : IPet { ... }
    public class Cat : IPet { ... }
    public class IPlanet : IMoves { ... }

    Single Responsibility Principle.  Interface Segregation Principle. 


    Wednesday, January 13, 2010 11:16 PM
  • Well Guys,

      Thank you for your replies , but I am sorry to say that I am not yet satisfied or I do not yet have a senario where I could say that 'In this senario abstract class must be used and interface won't work or In this senario Interface must be used and abstract class won't work'.

     Well my question is 'When to use Abstract class and when to use interface'?

    Can anyone explain me by giving a typical senario considering an application and explain the answer.
    zeeshan [ visit my forum: www.code4project.com ] [visit my blog: www.geekswithblogs.net/zeeshanjan]
    Thursday, January 14, 2010 11:20 AM
    • IS-A vs CAN-DO : If the derived type cant claim IS-A relation with base type then dont use base class.Where as interface implements the CAN-DO relation.
    • Ease Of Use : Generally its easy to extend a base class and add new functionality.With interface you will have to provide implementation for all the methods defined in it.So you need to decide ease of use factor too.
    • Consistent Implementation : With base type you can provide default implementation and that implementation will be shared by all child classes.But with interface implementation can vary.But again its not a drawback of interface but it all depends upon scenario.
    • Versioning : This is quiet important , if you have a base class and you add a new method the existing child classes will not be affected.But with interface if you add a new method to existing interface , you will break all the existing implementation.
    Thursday, January 14, 2010 12:04 PM
  • Well Guys,

      Thank you for your replies , but I am sorry to say that I am not yet satisfied or I do not yet have a senario where I could say that 'In this senario abstract class must be used and interface won't work or In this senario Interface must be used and abstract class won't work'.

     Well my question is 'When to use Abstract class and when to use interface'?

    Can anyone explain me by giving a typical senario considering an application and explain the answer.
    zeeshan [ visit my forum: www.code4project.com ] [visit my blog: www.geekswithblogs.net/zeeshanjan]


    Since you have found the examples and replies unsatisfactory up to this point, I suggest that you come up with this "typical scenario".  Gather opinions on the "typical scenario" that you come up with.

    Mark the best replies as answers. "Fooling computers since 1971."
    Thursday, January 14, 2010 2:08 PM
  • Well Guys,

      Thank you for your replies , but I am sorry to say that I am not yet satisfied or I do not yet have a senario where I could say that 'In this senario abstract class must be used and interface won't work or In this senario Interface must be used and abstract class won't work'.

     Well my question is 'When to use Abstract class and when to use interface'?

    Can anyone explain me by giving a typical senario considering an application and explain the answer.
    Sure here is one I use.

    When using a Factory Pattern always return an Interface while the objects underneath the interface adhere to an abstract. Why?

    1. Interfaces supply a contract of work . What will be done . The consumer doesn't care about the implementation, i.e. the guts of the code or the actual object being used.
    2. Since the user doesn't care about what actual object or class is being used. Putting in or replacing an object has no consequence on the consumer. No recompiles nothing. Just give them a new factory.
    The abstract is used to enforce business operations on a derived class or give base functionality which can be overridden. It is not targetted for end use (per-se), only to require that certain operations exist on a derived.

    I would use abstract to make the model /paradigm of what a derived class should do per business logic, and have that derived class adhere to an interface so consumers can use the class to target the actual end data logic goals.

    HTH
    William Wegerson (www.OmegaCoder.Com )
    • Edited by OmegaManMVP, Moderator Thursday, January 14, 2010 2:42 PM added per-se or it would have been questioned....
    • Marked as answer by Zeeshan Jan Saturday, January 16, 2010 3:48 AM
    Thursday, January 14, 2010 2:41 PM
  • Yes!
      Now this sems to be something I liked !
      Thanx !!!!
      Well I had learned the Factory Method Design Pattern but now I understand why we created Interfaces in that pattern and from the client code used the interfaces and not the actual base classes.
      I totally agree with you, but I need sometime to open my design pattern book and corelate the answer to the Factory Pattern.
      But But I think this is a very good answer......
    zeeshan [ visit my forum: www.code4project.com ] [visit my blog: www.geekswithblogs.net/zeeshanjan]
    Saturday, January 16, 2010 3:48 AM