Краткий ответ

Множественное наследование классов запрещено главным образом из-за неоднозначности состояния, реализации и конструкторов. Множественная реализация интерфейсов допустима, потому что интерфейс в первую очередь задаёт контракт, а состояние объекта и основной код находятся в единственном классе-родителе. Default-методы создают отдельные конфликты, но Java требует разрешать их явно.

Исторический контекст

Подход с одним непосредственным классом-родителем упрощает модель наследования: у объекта есть однозначная цепочка хранения состояния, вызова конструкторов и поиска унаследованных методов. При множественном наследовании классов возникает классическая проблема ромба: два родителя могут унаследовать общий базовый класс и предоставить разные реализации одного метода или одинаковые поля.

Интерфейсы позволяют отделить типовую совместимость от наследования реализации. Класс может поддерживать несколько контрактов, не получая несколько независимых наборов полей и конструкторов.

Постановка проблемы

Представим класс, который одновременно наследует поведение от двух классов. Если оба родителя объявляют метод с одной сигнатурой, непонятно, какую реализацию использовать. Если они содержат поле с одним именем, возникает неоднозначность доступа к состоянию.

Даже при отсутствии прямого конфликта пришлось бы определить порядок вызова конструкторов, правила размещения двух родительских частей объекта и алгоритм разрешения методов. Это усложнило бы язык и увеличило риск скрытых ошибок при изменении иерархии.

Подробное решение

У класса в Java может быть только один непосредственный суперкласс, поэтому реализация методов и состояние наследуются по одной цепочке. Дополнительно класс может реализовывать любое число интерфейсов, получая тем самым несколько типов, через которые объект допустимо использовать.

Интерфейс обычно не владеет экземплярным состоянием объекта. Его абстрактные методы задают обязательства класса, а одна реализация класса может удовлетворить нескольким одинаковым контрактам:

interface Printable {
    void print();
}

interface Loggable {
    void print();
}

class Report implements Printable, Loggable {
    public void print() {
        System.out.println("report");
    }
}

Здесь одного метода print достаточно для обоих интерфейсов, потому что сигнатуры совместимы и требуется одна операция.

Default-методы частично меняют картину: интерфейс может содержать готовую реализацию. Если два интерфейса предлагают конфликтующие default-методы, класс обязан предоставить собственную реализацию либо выбрать допустимого родителя интерфейса. Таким образом, множественная реализация не устраняет все конфликты, а переводит их в явно проверяемое правило разрешения.

Интерфейсные поля не являются обычным экземплярным состоянием: они неявно public static final. Поэтому реализация нескольких интерфейсов не создаёт несколько независимых копий изменяемых полей объекта, как это было бы при множественном наследовании классов.

Компромисс состоит в том, что класс иногда вынужден написать делегирующие методы или явно разрешать конфликт default-методов. Зато сохраняются простые правила владения состоянием и конструкторной инициализации.

Ситуация из практики

В библиотеке нужно описать объект, который можно сериализовать, отправлять в очередь и проверять на валидность. Вариант с несколькими базовыми классами был бы невозможен в Java и к тому же смешивал бы состояние разных подсистем.

Можно выбрать композицию: создать несколько служебных объектов и делегировать им работу. Плюс этого подхода — независимое состояние и возможность менять реализации; минус — дополнительный код делегирования.

Другой вариант — определить три интерфейса возможностей и реализовать их в одном классе. Это лучше, если интерфейсы описывают небольшие контракты без общего состояния. Выбранное решение обычно сочетает интерфейсы для публичных ролей и композицию для повторно используемой реализации: объект получает несколько типов, но сохраняет одного владельца состояния. В результате замена механизма сериализации не меняет иерархию классов и не создаёт конфликтов наследования.

Что кандидаты часто упускают

Вопрос: Может ли интерфейс сам расширять несколько интерфейсов?

Ответ: Да. Интерфейс может иметь несколько непосредственных суперинтерфейсов. Это также множественное наследование типов, а конфликты default-методов разрешаются правилами интерфейсного наследования или становятся обязанностью реализующего класса.
Вопрос: Всегда ли наличие default-методов делает множественную реализацию интерфейсов безопасной?

Ответ: Нет. Два независимых интерфейса могут предоставить default-методы с одинаковой сигнатурой, и класс не сможет оставить конфликт неразрешённым. Он должен объявить собственный метод; иначе конкретный класс не скомпилируется.
Вопрос: Решает ли интерфейс проблему повторного использования общего состояния так же, как базовый класс?

Ответ: Нет. Интерфейс не предоставляет обычных изменяемых экземплярных полей. Если нескольким классам нужно общее состояние и реализация, это обычно оформляют отдельным объектом и делегированием, абстрактным базовым классом либо другой формой композиции. Интерфейс сам по себе задаёт совместимый тип и поведение, но не единый экземпляр хранимого состояния.