This topic has been discussed many-a-times in the Saloon. Try a quick search on this forum, the intermediate forum, and the OO, Patterns and UML forum. Note that the search page link is at the top right of this page.

All classes are abstractions of real world things (abstraction = deciding what details are essential for modeling something). Abstract classes are a bit more abstract than "normal" classes because they (typically*) contain one or more abstract methods: that is, methods without bodies whose signatures specify (a) what services an object derived from that class must be able to perform, and (b) how to request such services (the method signature), but (c) without specifying HOW the object needs to do it. However, most abstract classes still have "concrete" data structures/attributes, which the implementing subclasses inherit. Hence, abstract classes in theory mandate, to a certain extent, what data should be used in carrying out the "mission" of an object, even if some of the behavioral details are open-ended. Interfaces are even more abstract than abstract classes, in that they consist ONLY of abstract method signatures (and potentially constant data values) -- no data structure in the form of attributes. That is, an interface describes a series of behaviors that an object implementing the interface must be able to perform WITHOUT prescribing the data structure that the implementing object must use to carry out those behaviors. * It is possible to declare a class to be abstract even if it doesn't contain abstract methods ...