Feb 02, 2011
Compared to interfaces abstract classes can have implementation. Without implementation an abstract class does the same as an interface but C# allows you to inherit from / implement multiple interfaces but inherit from one base class only.
An interface once deployed is "frozen" - you must not change a deployed interface. If you change an interface you break binary compatibility but you can extend an abstract class as long as you don't change method signatures.
Feb 06, 2011
Use Abstract class when there is a 'IS-A' relationship between classes. For example, Lion is a Animal, Cat is an Animal. So, Animal can be an abstract class with common implementation like no. of legs, tail etc.
Feb 09, 2011
As Ricky says. When two classes share the same properties or method the common denominator is your abstract class. There are many benefits aside from this. but when you have to change a property type for e.g. D.on't R.epeat Y.ourself
Feb 14, 2011
I think the most of the answers above are explained the need for Base/derived classes. In my knowledge the abstract class will contain a concrete method which can not be override by the derived classes. Means if you DON'T want to change one basic business rule(the concrete method) defined in the base (abstract) class by the derived classes, then go for abstract class with the concrete method.
Feb 23, 2011
Basically Abstract class should be used for 'is-a' relationship and Interface should be used for 'has-a' relationship.
If we want to retrict all the subclasses must have certain functionality, then Abstract class with implementation is recomended. So, overriding already implemented member in the subclasses is not a good practice here.
In a particular class, where there are more behaviours that will get change during runtime, then implementing from multiple interfaces are recommended.
Oct 01, 2013
When to use Abstract and when to use Interface
1. If you are creating something that provides common functionality to unrelated classes, use an interface
2. Abstract classes allow you to provide default functionality for the subclasses.
3. If you are creating something for objects that are closely related in a hierarchy, use an abstract class
4. If the base class will be changing often and an interface was used instead of an abstract class, we are going to run into problems. Once an interface is changed, any class that implements that will be broken. Now if it’s just you working on the project, that’s no big deal. However, once your interface is published to the client, that interface needs to be locked down. At that point, you will be breaking the clients code
5. Compared to interfaces abstract classes can have implementation. Without implementation an abstract class does the same as an interface but C# allows you to inherit from / implement multiple interfaces but inherit from one base class only.
6. An interface once deployed is "frozen" - you must not change a deployed interface. If you change an interface you break binary compatibility but you can extend an abstract class as long as you don't change method signatures.
Use an abstract class
When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)
Use an abstract class to define a common base class for a family of types.
Use an abstract class to provide default behavior.
Subclass only a base class in a hierarchy to which the class logically belongs.
Use an interface
When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.
Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.
Use an interface to design a polymorphic hierarchy for value types.
Use an interface when an immutable contract is really intended.
A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.