What are the differences between an abstract class and an interface?

Answer 1, authority 100%

A short distinction.

An abstract class is a class that does not have one or more methods implemented (some languages ​​require such methods to be marked with special keywords).

An interface is an abstract class with none methods implemented, all of them are public and there are no class variables.

An interface is usually needed when only an interface is described (tautology). For example, one class wants to give another the ability to access some of its methods, but does not want to “reveal” itself. So it just implements the interface.

An abstract class is needed when you need a family of classes that have a lot in common. Of course, you can use the interface, but then you will need to write a lot of identical code.

In some languages ​​(C++) there is no special keyword to denote interfaces.

Any interface can be considered an abstract class, but not vice versa.

Answer 2, authority 46%

tl; dr: An abstract class is a low-level class development tool, a tool for code reuse; an interface is a means of expressing the semantics of a class. Thus, these are completely different, little related concepts.

Think about it differently.

Abstract class is a “stub” of a class: most of the methods (including internal ones) are implemented, except a few. These few unimplemented methods may well be internal methods of the class, they only clarify the implementation details. An abstract class is a facility for code reuse, a facility for specifying which method must be overridden to complete the writing of the class.

Interface is a kind of contract: interfaces are used in definitions to indicate that the object that will actually be used should implement (for input parameters) or will be guaranteed to implement (for output parameters) a set of methods and (more importantly!) have certain semantics. The interface may well be empty, however, to implement the interface means to support this semantics.

Abstract classes are ideologically similar to templates C++: both are prefabricated classes, but the template needs to specify the template types to get the class, and the abstract class needs to specify abstract methods.

Interfaces are ideologically similar to C++ header files: they expose methods and hide a specific implementation.

The question of whether an interface or an abstract class is actually a class is a technical implementation detail that depends on a particular programming language. For example, in C++ there are no interfaces at all, and they have to be emulated with classes without data. There is no abstract class in C++ as such either, but it can be considered any class with abstract methods. (Hence the C++ limitation: at least 1 abstract method in an abstract class.) Also in C++, you can (indirectly) instantiate an abstract class, call an abstract method, and (possibly) get a runtime error. In C #, interfaces and abstract classes are built into the language.

Example (in C #, the specific language does not matter):

// common code for all animals
abstract class Abstract
{
  public int Age {get; protected set; }
  public int Weight {get; protected set; }
  public bool Sleeping {get; protected set; }
  public void SubmitVoice ()
  {
if (! Asleep & amp; & amp; Age & gt; Age CutVoice)
      ImplementationSubmitVoice ();
  }
  abstract protected void ImplementationSubmitVoice ();
  readonly protected int Age of CutVoice;
}
class Dog: Abstract
{
  override protected void ImplementationSubmitVoice ()
  {
    Woof ();
  }
  public void woof ()
  {
    // implementation
  }
  public Dog () {VoiceCut Age = 2; }
}
class Cat: Abstract
{
  override protected void ImplementationSubmitVoice ()
  {
    Meow();
  }
  public void Meow ()
  {
    // implementation
  }
  public Cat () {VoiceCut Age = 1; }
}

interface Ianimal
{
  int InventoryNumber {get; }
}
class Lion: Zoo Dweller, Animal
{
  // ...
}
class Zebra: Zoo Dweller, Animal
{
  // ...
}
class Guardian: Zoo Dweller
{
}
// ...
void Inventory ()
{
  List & lt; Zoo Dweller & gt; inhabitants = // ...
  foreach (var dweller in dwellers)
    if (inhabitant is Ianimal) // separate animals from non-animals
      Add Animal ((I Animal) inhabitant);
}
void AddAnimal (IAnimal) // only an animal can get here
{
  ...

Answer 3, authority 36%

I find it curious enough that this question is tagged “oop”, but at the same time, in many answers, specific aspects of specific programming languages ​​are clearly leaking out. I will try to give an answer based on the concepts of OOP and only then show why this difference appeared in some programming languages.

Abstract classes and interfaces have a certain relationship to inheritance, more precisely to modeling the world. With their help, we want to express that a certain group of things in our system has something in common: some common behavior that distinguishes this group of gizmos from all others.

For example, let’s say we want to model buttons in the user interface. Since we are talking about OOP, we will single out a certain type of Button with a certain set of operations (which determine the behavior) and a hidden state on which the behavior is based (yes, there may not be a hidden state). At the same time, we can distinguish three types of operation:

• A specific fixed operation that must be absolutely stable for all types of buttons.

• A specific operation with default behavior (i.e. an operation whose behavior is suitable for many types of buttons, but there may be buttons with different behavior).

• Declaration of an operation without a specific implementation (i.e. an operation whose behavior cannot be determined, because at this stage reasonable default behavior is not known, or operations may differ too much for different buttons ).

In other words, the Button type can contain non-virtual methods , virtual methods (virtual methods), and abstract methods ( abstract methods).

Having different types of methods is a very important modeling tool and allows you to very accurately express the intent of the designer. For example, we can add a non-virtual operation “Pressing the button”, which will delegate some of its work to the virtual (or abstract method) “Handle the press”, but at the same time always perform a certain part of the work (the discerning reader will see in this description the pattern “Template method” ).

After we have defined the base type, it’s time to define arbitrary types. And here the questions begin. More precisely, no questions arise when a type has only one immediate base type, or all base types contain only operation declarations. No problem, inherit the “Menu Button” from the “Button” and override the “Press the button” method. But what if our type “Menu Button” is inherited from two types with the same virtual operation? How to override just one and keep the other? But what about a new type of client and distinguish which operation to call? What if two base types have a field with the same name? But what if one basic type has the “Press the button” method implemented, while the other has only a declaration?

No, all these problems can be solved, and in C++, Eiffel, and other programming languages, you can quite flexibly control what and how to override, what to hide, what to expose and how to call a method of a certain base type. But for the authors of some programming languages, such complexity seemed unnecessary, and they went for a trick and separated the types that contain only method declarations into a separate category, and this is how interfaces appeared .

It will now be easy to distinguish between the three concepts – an interface, an abstract base class, and a concrete base class.

• Interface – describes a certain family of types and contains only declarations of operations (yes, I deliberately write the word “declaration”, and do not use the word “contract”, which in OOP has a very definite meaning ).

• An abstract base class describes a family of types, but in addition to the declaration of operations, it can contain default implementations (virtual methods) and fixed operations (non-virtual methods).

• Concrete class describes some family of types that are ready for use by clients. Such a class cannot contain declarations of operations and all of its operations must be either fixed (non-virtual methods) or contain a default implementation (virtual methods). There is another subtype of concrete classes – sealed class – this is a kind of a concrete class that cannot be inherited from, which means it can only contain specific operations.

Separating interfaces into a separate category is useful not only from the point of view of simplifying the implementation of programming languages, but also for highlighting different approaches to modeling. So, for example, class inheritance models the relationship “Is” (“Menu button” IS “Button”), and base classes usually contain certain functionality that is closely related to the functionality of the derived class. Base classes not only model a group of types, but also allow you to reuse existing functionality.

Interfaces, by their very nature, have less coupling (low coupling), since they do not have specific behavior that can complicate the life of a descendant class. Interfaces can also model the Is relationship (Menu Button IS Ibutton), but they can define a less rigid CAN DO (CAN DO) relationship. For example, the BCL’s IEquatable interface defines “additional” behavior that indicates that types can compare object values.

Answer 4, authority 11%

Differences between an abstract class and an interface in Java

std :: vector & lt; IHellower * & gt; mArr;
class IHellower {
   virtual void Hello () = 0;
}

class SomeThingLikeABall
{
    private:
      int radius;
      int weight;
    public:
      bool canPlayFootballWithIt () = 0;
      void draw () = 0;
}

ps - for moderators, why can't I comment?