Abstract classes and interfaces - when to use one or the other?

Question

OOP

Hello
As far as I understand, abstract classes are used to highlight the generality in the implementation, and interfaces - for the generality in behavior. But why can't the generality of behavior be isolated in abstract methods?
For example, there is an abstract class animal with a method to breathe. Descendants implement an interface with a "make a sound" method. But why can't this method be taken as abstract in the "animal" class? When should one or the other be used?

Answer 1

As for me, these associations from the real world only complicate the understanding of OOP.
An interface is a description of the methods for accessing an object.
An abstract class is a selection of common methods and properties of classes.

Answer 2

It all depends on what you want. And in general, there are many options with “optional” functionality (for simplicity, I write in Java).
1. "Type according to OOP".

class Animal {}
class Dog extends Animal {
   public void doSound() {}
}

Disadvantage: if we have a dog with sound, a cat with sound and a duck with sound and we need to make a sound, if possible - poof!
2. Implement the Vocal interface

interface Vocal {
  void doSound();
}
class Animal {}
class Dog extends Animal implements Vocal {
   @Override
   public void doSound();
}

In this case

if (animal instanceof Vocal)
  ((Vocal)animal).doSound().

However, such type conversions are also slightly not according to OOP.
3. Not sure if it's possible in Java, I'll write it in C++. Protected doSound in Animal and public in Dog.

class Animal {
protected:
   void doSound();
};
class Dog : public Animal {
public:
  using Animal::doSound;
};

The disadvantage is that if you still have to organize common functionality, then you have to write the “Public Morozov” template.
Example: All VCL components have protected __property Caption. And in 99% of cases this is enough: the title is displayed somewhere - pull it out. I have a question with automatic translation of forms. Either connect introspection, or Public Morozov (in Delphi/Builder there is introspection and an additional published access right that connects a property to it). I did not suffer and did the second.
Also, the task is somewhat inconvenient when the library lives and develops for a long time: with each new version, more and more new properties have to be brought out
Pros? Simple, low memory consumption and convenient to write special tasks. For example, the Hint property is protected but in effect; if the tooltip is some kind of dynamic and you can’t change it from the outside, change it to health from the inside.
PS. Came home from work, the same in Java.

public class Dog extends Animal {
    @Override
    public void doSound() { super.doSound(); }
}

Well, the role of Morozov will be played by the introspection API and the Morozov class in the same package. We all forget that protected covers a more rigid package, i.e. from the same package is also possible.

public static void main(String[] args) {
        Animal an = new Animal();
        an.doSound();   // protected!
    }

4. Can it make sound?

class Animal {
public boolean isVocal() { return false; }
public void doSound() {}
}

5. Return the Vocal interface; if null, the animal is silent.

class Animal {
public Vocal getVocal() { return null; }
}

What to choose - there is no clear answer. How much will be inherited from this class, how many common tasks will be and how much documentation will be overloaded ... Let's say if we do not have access to the Animal class, the second is tempting. And if Vocal is not an interface, but an abstract class, then the fifth one.

Answer 3

Interface - when you need to work uniformly with different objects that have the same logical purpose (entity repositories, for example).
Abstract class - when you need to define some uniform behavior for all derived objects, as well as differences in behavior - abstract methods.