A question often arises about the use of class inheritance (such as an abstract base class) or interfaces, and which solution is better.  There are pros/cons to both.  For instance, interfaces can be used even when a class inherits from another class.  Interfaces are also commonly used in several libraries.  For example, mocking libraries make extensive use of interfaces.  However, because interfaces only define the properties and methods to use and not the implementation, they are harder to implement.  This is a benefit to base classes because they can provide the underlying architecture without you have to write extra code.

For certain problems, however, the answer may be both.  In certain situations, a class is forced to inherit from another class (such as with an ASP.NET control which can implement IWebPart to utilize web part capabilities).  By creating both a base class and an interface, you open up the possibility to include more than one type of object to incorporate this functionality.  So, by having the following interface/class as your base, the both custom objects and existing objects can make use of the change tracking features (to be discussed later).

Listing 4

public abstract interface IDomainEntity
{
  bool IsDirty { get; }
  void ClearDirtyStatus();
  void SetDirty();
}

The base class can implement the interface as such below:

Listing 5

public class DomainEntity: IDomainEntity
{
  private bool _isDirty = false;
 
  #region " Properties "
 
  protected bool IsDirty
  {
    get
    {
      return _isDirty;
    }
  }
 
  bool IDomainEntity.IsDirty
  {
    get
    {
      return this.IsDirty;
    }
  }
 
  #endregion
 
  #region " Methods "
 
  protected void ClearDirtyStatus()
  {
    _isDirty = false;
  }
 
  void IDomainEntity.ClearDirtyStatus()
  {
    this.ClearDirtyStatus();
  }
 
  protected void SetDirty()
  {
    _isDirty = true;
  }
 
  void IDomainEntity.SetDirty()
  {
    this.SetDirty();
  }
 
  #endregion
}

Clearly there will be cases for both situations.