toString (), равняется (), и хэш-код () в интерфейсе

Я действительно смещаюсь, и это - явная реклама...

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

Выезд демонстрация на моем веб-сайте .

52
задан gvlasov 25 May 2015 в 07:42
поделиться

10 ответов

Все объекты в Java наследуются от java.lang.Object и Объект предоставляет реализации этих методов по умолчанию.

Если ваш интерфейс содержит другие Java будет жаловаться, если вы не реализуете интерфейс полностью, предоставив реализацию этих методов. Но в случае equals () , hashCode () и toString () (а также некоторых других, о которых вы не упомянули) реализация уже существует.

Один из способов добиться того, что вы хотите, - это предоставить другой метод в интерфейсе, скажем, toPrettyString () или что-то в этом роде. Затем вы можете вызвать этот метод вместо метода по умолчанию toString () .

39
ответ дан 7 November 2019 в 09:12
поделиться

well if u have declared an interface in which by default all the methods are abstract and u do need to provide the functionality but when u implement it in the subclass, then u provide the implementation right. as you can see that every class is the subclass of one superclass(put simply Object is superclass of all the classes) so if u have a class implementing an interface, u need to provide implementation for the methods. but a thing needs to be remembered here that.

irrespective of, if u didn't declare these methods in the interface, you still had this behavior for the subclass that implemented the interface in the first place.

so if don't declare it, it still will be present and another thing is that since these methods and other methods of Object class are present for all the objects of classes, so there is no need for implementation.

-2
ответ дан 7 November 2019 в 09:12
поделиться

Java заботится только о том, чтобы методы были где-то определены. Интерфейс не заставляет вас переопределять методы в новых классах, которые наследуются от интерфейса в первый раз, если они уже определены. Поскольку java.lang.Object уже реализует эти методы, ваши новые объекты соответствуют интерфейсу, даже если они не переопределяют эти три метода сами по себе.

3
ответ дан 7 November 2019 в 09:12
поделиться

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

4
ответ дан 7 November 2019 в 09:12
поделиться

Другие люди достаточно ответили на ваш вопрос. Что касается решения вашей конкретной проблемы, вы можете подумать о создании своих собственных методов (возможно, getStringRepresentation, getCustomHashcode и equalsObject), и попросите ваши объекты расширить базовый класс, методы equals, toString и hashCode которого вызывают эти методы.

Однако это может вообще лишить смысла использование интерфейса. Это одна из причин, по которой некоторые люди считают, что equals, toString и hashCode вообще не должны быть включены в класс Object.

3
ответ дан 7 November 2019 в 09:12
поделиться

Реализация этих методов идет полностью от Object .

5
ответ дан 7 November 2019 в 09:12
поделиться

Любой класс, реализующий ваш интерфейс, также расширяет Object. Object определяет hashCode, equals и toString и имеет реализации по умолчанию всех трех.

То, что вы пытаетесь достичь, хорошо, но неосуществимо.

7
ответ дан 7 November 2019 в 09:12
поделиться

All 3 of those methods are defined by java.lang.Object which is (implicitly) extended by all other classes; therefore default implementations for those methods exist and compiler has nothing to complain about.

17
ответ дан 7 November 2019 в 09:12
поделиться

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

public abstract class MyBaseClass implements ... /* existing interface(s) */ {

    public abstract boolean equals(Object other);

    public abstract int hashCode();

    public abstract String toString();
}

Затем измените ваши текущие классы на , расширьте этот класс.

Такой подход работает, но не является идеальным решением.

  • Это может быть проблематичным для существующего класса. иерархия.

  • Это плохая идея заставлять классы, реализующие ваш существующий интерфейс, расширять определенный абстрактный класс. Например, вы можете изменить параметры в сигнатурах методов, чтобы использовать абстрактный класс, а не существующие интерфейсы. Но конечный результат - менее гибкий код. (И люди все равно могут найти способы подорвать это; например, путем добавления собственного абстрактного подкласса, который «реализует» методы с помощью super. (...) call!)

  • Наложение определенного шаблона иерархии / реализации классов недальновидно. Вы не можете предсказать, будет ли какое-либо изменение требований в будущем означать, что ваши ограничения вызовут трудности. (Вот почему люди рекомендуют программировать с использованием интерфейсов, а не конкретных классов.)


Вернемся к вашему собственному вопросу о том, почему ваш интерфейс не заставляет класс повторно объявлять эти методы:

Почему это не будет принудительно для меня ? Он жалуется, если я не реализую какие-либо другие методы, но не применяет эти три. Что дает? Есть какие-нибудь подсказки?

Интерфейс накладывает ограничение, заключающееся в том, что конкретный класс, реализующий его, имеет реализацию для каждого из методов. Однако это не так. Требуется, чтобы сам класс реализовывал эти методы. Реализации метода могут быть унаследованы от суперкласса. И в данном случае именно это и происходит. Методы, унаследованные от java.lang.Object , удовлетворяют ограничению.

JLS 8.1.5 утверждает следующее:

«Если объявленный класс не является абстрактным, все абстрактные методы-члены каждого прямого суперинтерфейса должен быть реализован (§8.4.8.1) либо объявлением в этом классе , либо существующим объявлением метода, унаследованным от прямого суперкласса или прямого суперинтерфейса , потому что класс, который не является абстрактным, является не разрешено иметь абстрактные методы (§8.1.1.1). "

40
ответ дан 7 November 2019 в 09:12
поделиться

Если вы хотите принудительно переопределить equals () и hashCode (), расширьте абстрактный суперкласс,

5
ответ дан 7 November 2019 в 09:12
поделиться
Другие вопросы по тегам:

Похожие вопросы: