Похоже, вы хотите заставить ваши классы переопределить реализации этих методов по умолчанию. Если это так, то способ сделать это - объявить абстрактный суперкласс, методы которого объявлены как абстрактные. Например:
public abstract class MyBaseClass implements ... /* existing interface(s) */ {
public abstract boolean equals(Object other);
public abstract int hashCode();
public abstract String toString();
}
Затем измените текущие классы на extend
этот класс.
Этот подход работает, но он не идеальное решение.
Это может быть проблематично для существующей иерархии классов.
Это плохая идея заставить классы, которые реализуют ваш существующий интерфейс, расширять определенный абстрактный класс. Например, вы можете изменить параметры в сигнатурах методов, чтобы использовать абстрактный класс, а не существующие интерфейсы. Но конечный результат - менее гибкий код. (И люди в любом случае могут найти способы подорвать это; например, добавив свой собственный абстрактный подкласс, который «реализует» методы с помощью вызова super.<method>(...)
!)
Наложение определенной иерархии классов / шаблона реализации недальновидно. Вы не можете предсказать, будет ли какое-то будущее изменение требований означать, что ваши ограничения вызовут трудности. (Вот почему люди рекомендуют программирование с использованием интерфейсов, а не конкретных классов.)
Возвращаясь к вашему актуальному вопросу о том, почему ваш интерфейс не заставляет класс переопределять эти методы:
Почему это не будет навязано мне? Он жалуется, если я не реализую другие методы, но не применяет эти три. Что дает? Любые подсказки?
Интерфейс налагает ограничение на то, что конкретный класс, реализующий его, имеет реализацию для каждого из методов. Однако не требуется, чтобы сам класс реализовывал эти методы. Реализации метода могут быть унаследованы от суперкласса. И в этом случае именно это и происходит. Методы, унаследованные от java.lang.Object
, ограничивают ограничение.
JLS 8.1.5 гласит следующее:
"Если объявленный класс не является абстрактным, все абстрактные методы-члены каждого прямого суперинтерфейса должны быть реализованы (§8.4.8.1) либо объявлением в этом классе , либо существующим объявлением метода, унаследованным из прямого суперкласса или прямого суперинтерфейса , потому что классу, который не является абстрактным, не разрешается иметь абстрактные методы (§8.1.1.1). "