Почему в Java нет множественного наследования, но разрешена реализация нескольких интерфейсов?
Это не имеет никакого отношения к неизменности целых чисел; это связано с тем, что Java является Pass-by-Value, Dammit! (Не раздражает, просто заголовок статьи: p)
Подводя итог: вы действительно не можете сделать swap-метод в Java. Вам просто нужно сделать своп самостоятельно, где бы вы ни нуждались; это всего лишь три строки кода в любом случае, поэтому не должно быть такой большой проблемы:)
Thing tmp = a;
a = b;
b = tmp;
7 ответов
Потому что интерфейсы определяют только что делает класс, а не как он это делает.
Проблема с множественным наследованием заключается в том, что два класса могут определить разные способы выполнения одного и того же действия, и подкласс не может выбрать, какой из них выбрать.
Возьмем, к примеру, случай, когда класс A имеет метод getSomething, а класс B - метод getSomething, а класс C расширяет A и B. Что произойдет, если кто-то называется C.getSomething? Невозможно определить, какой метод вызывать.
Интерфейсы в основном просто указывают, какие методы должен содержать реализующий класс. Класс, реализующий несколько интерфейсов, просто означает, что класс должен реализовать методы из всех этих интерфейсов. Whci не приведет к каким-либо проблемам, описанным выше.
По той же причине C # не допускает множественное наследование, но позволяет реализовать несколько интерфейсов.
Урок, извлеченный из C ++ с множественным наследованием, заключался в том, что он приводит к большему количеству проблем, чем того стоит.
Интерфейс - это договор вещей, которые должен реализовать ваш класс. Вы не получаете никакой функциональности от интерфейса. Наследование позволяет вам наследовать функциональность родительского класса (а при множественном наследовании это может сильно запутать).
Разрешение нескольких интерфейсов позволяет вам использовать шаблоны проектирования (например, адаптер) для решения тех же типов проблем, которые вы можете решить с помощью множественного наследования, но гораздо более надежным и предсказуемым способом.
] Потому что интерфейс - это просто контракт. А класс на самом деле является контейнером для данных.
Поскольку наследование используется слишком часто, даже когда вы не можете сказать «эй, этот метод выглядит полезным, я расширю этот класс как хорошо".
public class MyGodClass extends AppDomainObject, HttpServlet, MouseAdapter,
AbstractTableModel, AbstractListModel, AbstractList, AbstractMap, ...
Один из моих преподавателей в колледже объяснил мне это следующим образом:
Предположим, у меня есть один класс - тостер, а другой - Ядерная бомба. У них обоих может быть настройка «тьма». У них обоих есть метод on (). (У одного есть выключение (), у другого - нет.) Если я хочу создать класс, который является подклассом обоих этих ... как вы можете видеть, это проблема, которая действительно может взорваться у меня здесь.
Таким образом, одна из основных проблем заключается в том, что если у вас есть два родительских класса, они могут иметь разные реализации одной и той же функции - или, возможно, две разные функции с одним и тем же именем, как в примере с моим инструктором. Затем вам нужно решить, какой из подклассов будет использовать. Конечно, есть способы справиться с этим - это делает C ++, но разработчики Java чувствовали, что это слишком усложнит задачу.
Однако с интерфейсом вы описываете то, что класс способен делать, а не заимствуете метод чего-то другого класса. Несколько интерфейсов с гораздо меньшей вероятностью вызовут сложные конфликты, которые необходимо разрешить, чем несколько родительских классов.
Реализация нескольких интерфейсов очень полезна и не вызывает особых проблем ни у разработчиков языка, ни у программистов. Так что это разрешено. Множественное наследование, хотя и полезно, может вызвать серьезные проблемы для пользователи (ужасный алмаз смерти ). И большинство вещей, которые вы делаете с множественным наследованием, также можно сделать с помощью композиции или использования внутренних классов. Таким образом, множественное наследование запрещено, поскольку оно приносит больше проблем, чем приносит пользу.
{{ 1}}