How can you explain the difference between an interface and an abstract class to a non-programmer? [duplicate]

Answer 1

Very simply put, an interface defines how you can talk to me.

Whereas an abstract class could define one of my talents such as playing the guitar. The problem is that "playing guitar," by itself isn't really that useful. But we could use this ability to create a type of person, such as a musician (which we could say is a class).

Answer 2

Interface: The buttons of the remote control. Users know how these buttons are supposed to function.

Concrete class: Toshiba RC, Philips RC, JVC RC - what's inside the box is the concrete implementation.

Answer 3

Interface

An interface is simply a specification. It describes what something MUST do. Nothing more, nothing less. On its own, it is meaningless. It is only useful when someone takes that specification and implements it.

Think of a USB memory stick. It conforms to the specifications of USB. A device communicating with it doesn't need to know or care how the memory stick is going about its job, all it needs to know is that when we ask for data to be written, it is written; conversely, when we ask to read data from it we expect to receive the data.

In computing terms, we use an interface in the same way. If we have:

public interface IUSB
{
    Data Read();
    bool Write(Data data);
}

We know that anything implementing this interface has to provide an implementation for Read and Write. How or what it does behind the scenes is of no concern to us. By passing an interface around our code we're not tying ourselves down to specific implementations.

Abstract Class

An Abstract Class simply provides us with a means to put in place specification in a base class that derived types must implement, as well as common code that can be used by all derived types.

I've been trying to thing of a good real-world example and have struggled, so can only really come up with a code example.

Say you wanted to implement an employee hierarchy in your code. So you may have:

public abstract class Employee
{
    public string FirstName { get; protected set; }
    public string LastName { get; protected set; }
    public string Grade { get; protected set; }
    public int Salary { get; protected set; }
    public abstract void GivePayRise();
}

Every employee has a name and an associated job grade. We can model this in the base class with the first 3 properties. However, giving a bonus may not be a straightforward affair, depending on grade etc. So, we mark this as abstract. Every derived type of Employee (Part-Time, Full-Time, Contract, Consultant) has to implement this.

An implementation may be:

public class FullTimeEmployee : Employee
{
    public void GivePayRise()
    {
        Salary *= 1.1;
    }
}

public class PartTimeEmployee : Employee
{
    public void GivePayRise()
    {
        Salary *= 1;
    }
}

So we want to give a 10% raise to full-time employees, but nothing to part-time ones.

Difficult to give good examples - I generally tend to use interfaces, can't really remember in the past year or so when I've used an abstract class. This could start the whole Abstract Class vs Interface debate, but that's a whole new page.......