Trying to get a real world concept of Abstract class vs Interface in asp.net

Question

I have searched through the numerous S/O postings and have not found an answer that helps me.
I would like to get a mental vision of what is an abstract class and what is an interface. I have read through this post Real world abstract class usage simple samples, but I am still not clear about the concepts.

I am hoping someone can describe a real world in the form of an "Person" object. So inheritance would be "Person" --> "Employee" --> "Manager"
And Overriding would be "Employee's Salary" would become "Sales employee commission"

How can I describe an abstract class and an interface within a Person object concept?

Answer 1

OK, let's see if I understood your question...

I think your conceptaully unsure of the differences and/or similarities between the use of interfaces and abstract classes. If thats the issue then heres my "starter for 10" summary;

Abstract classes cant be instantiated, but can contain implementation details, so when deriving a class from one you get the contract and any default behavior you put in the abstract class. For example your Person class (I'll assume its an abstract class for this example) would define the contract a derived Employee or Manager class must (at least) have, but can also provide some default behaviour.

Interfaces on the other hand only specify the contract; what implementing classes must do, they cannot provide any manner of implementation. For example if the "Person" in your example was infact an interface it wohuld define what classes implementing it (the Employee and Manager) must do, but cannot provide any default implementation for that contract.

Also note that in many languages (Java, C#, Delphi) you can inherit from only one parent class, but can implement many interfaces.

Answer 2

I apologize that I am not using your person example, please take this as an extended comment only.

I find it easiest to explain the concepts, to people with no programming background, using an analogy to something most people already understand: Plastic molding!

Lets say we are making plastic fruit for instance:

An interface is like the mold, it has the shape of the final product, but you can fill it with all kinds of different colors and materials. They will all have the same shape in the end, even if they are completely different in color and texture.

An abstract class would be more like something that needs an extra step, like painting. You create the basic plastic fruit, then sent it off to get some painting or fur glued on or something.

The unfinished fruit is like an abstract class in that is has more definition of the final product then the mold does, but it in itself is not complete. It needs more work to be completed, and the end products could be completely different colors, but they are still basically the same.

I hope that helps!

Answer 3

There are different views on the subject of using an interface versus abstract class. An interface, though, should express the behavior of an object (what it can do) and the abstract class should define what it is. Basically "I can" versus "I am" from the object's persepective.

So, if we have a Person, that is a noun and so we'll use an abstract class to define it. Any thing that "is a" Person will inherit from that class. If we want to define some behaviour that describes some behavior that the Person is capable of that doesn't extend to all Persons, we should put that into an interface.

Using the relationship that you defined (Person -> Employee -> Manager), we can say that the Employee implements IFirable and the Manager implements IFirer. The employee can be fired, and the manager can fire an employee.