What is preferable? To create Abstract base classes to inherit from? Or to design Interfaces to implement them in other objects?
While it is up to the characteristics of your application project to decide whether to design interfaces or abstract classes, there are some very important points to have clear before you start developing your software.
Essentially, an Interface is just an empty contract, while an Abstract Class is really a plain standard class, but containing at least one abstract member. An Abstract Class can contain indexers, constants, fields, properties and plenty functional methods.
First, let's see some examples of abstract inheritance and some of interfaces implementation.
The following graph represents an inheritance chain from abstract classes :
The abstract classes can have its own inner functionality and concrete methods, as you can see in the following code:
abstract class Parent
{
public abstract void DoIt();
}
This is an abstract base class, no functionality. And this other one is also abstract, but inherits from the former, and owns some behavior:
abstract class Base : Parent
{
protected Parent component;
public void Setup(Parent component)
{
this.component = component;
}
public override void DoIt()
{
if (component != null)
{
component.DoIt();
}
}
}
This last one inherits from the abstract class:
class Child : Base
{
public override void DoIt()
{
base.DoIt();
ExtendedFunctionality();
Console.WriteLine("You are at Child .DoIt()");
}
void ExtendedFunctionality()
{
{
public override void DoIt()
{
base.DoIt();
ExtendedFunctionality();
Console.WriteLine("You are at Child .DoIt()");
}
void ExtendedFunctionality()
{
// TODO
}
}
}
}
Interfaces are just empty contracts:
interface IContract
{
void DoIt();
}
class SomeClass : IContract
{
public void DoIt()
{
// TODO
}
}
I have summarized in this table the main differences between interfaces and abstract classes:
Characteristics
|
Interfaces
|
Abstract
Classes
|
Definition
|
Empty contract
|
Class with at
least one abstract member
|
Functionality
|
No: just empty
methods
|
Yes : all kind
of class behavior
|
Access modifiers
|
No : all
public
|
As you wish
|
Relevance
|
Adds secondary
functionality to a class
|
Intended to be
used as Base or Core Class
|
Performance
|
Wastes time
searching the appropriate method
|
Fast
|
Properties
|
Yes : always
empty
|
Yes
|
Constants, Fields & Indexes
|
No
|
Yes
|
Multiple Inheritance
|
Yes: a class
can implement several interfaces
|
No: a class
can have only one base class
|
Versioning
|
Not recommended
|
Straightforward
|
Important:
Before you start building some project or application take into account the versioning problem: if after you deployed the software, it happens to be that you must add new behavior to an interface (adding a new method to an existing interface), the whole application will cease working, because at compile time the classes which implement the interface will incur in error while lacking the new method's implementation.
However, if you add a new method to an abstract base class, the application will keep running, because the child classes do not have to implement the method necessarily. It can remain unimplemented until you want.
Before you start building some project or application take into account the versioning problem: if after you deployed the software, it happens to be that you must add new behavior to an interface (adding a new method to an existing interface), the whole application will cease working, because at compile time the classes which implement the interface will incur in error while lacking the new method's implementation.
However, if you add a new method to an abstract base class, the application will keep running, because the child classes do not have to implement the method necessarily. It can remain unimplemented until you want.
Happy programming.....
By Carmel Schvartzman
כתב: כרמל שוורצמן
No comments:
Post a Comment