Reason to use BOTH abstract classes and interfaces? (Abstract class implements interface)

Question

Recently I have come across a curious pattern in some code. We know that there is a time and a place for everything, especially when it comes to the issue of ABCs and interfaces, but this just seems redundant to me.

  // This describes a person....   public interface IPerson   {     public string FirstName { get; set; }     public string LastName { get; set; }     public int BasePay { get; set; }     public string Address { get; set; }   }    // And so does this, but it also uses the interface....   public abstract class Person : IPerson   {     public string FirstName { get; set; }     public string LastName { get; set; }     public int BasePay { get; set; }     public string Address { get; set; }   }    // This uses both ?!   public class CoalMiner : Person, IPerson   {     public CoalMiner()     {       BasePay = 10000;     }   } 

Can anybody think of what the specific advantage of using both and ABC and an interface that define the same members be?

Answer 1

Personally, I feel that using an interface to describe a "noun", such as a person, it typically a poor design choice.

Interfaces should be used for contracts - all people are always a Person, so an abstract class makes more sense here. Interfaces could be added for behaviors attached to specific types of people, or to allow a Person to be used in a certain way by fulfilling a contract (ie: Person : IComparable<Person>).