Чому .compareTo () в інтерфейсі, а .equals () знаходиться в класі на Java?

Хочу знати, чому .compareTo()в Comparableінтерфейсі, а такий метод, як .equalsу Objectкласі. Мені здається довільним, чому такий метод, як, наприклад, .compareTo()вже не в Objectкласі.

Для використання .compareTo()ви реалізуєте Comparableінтерфейс та реалізуєте .compareTo()метод для своїх цілей. Для .equals()методу ви просто перекриєте метод у своєму класі, оскільки всі класи успадковують від Objectкласу.

Моє питання: чому такий метод, як .compareTo()в інтерфейсі, який ви реалізуєте, а не в класі, як Object? Так само, чому .equals()метод реалізується в класі, Objectа не в якомусь інтерфейсі?

Не всі об'єкти можна порівняти, але всі об’єкти можна перевірити на рівність. Якщо нічого іншого, то можна побачити, чи є два об’єкти в одному місці в пам'яті (еталонна рівність).

Що це означає для compareTo()двох Threadоб'єктів? Як одна нитка "більша за" іншу? Як ти порівнюєш дваArrayList<T> с?

ObjectДоговір стосується всіх класів Java. Якщо навіть один клас не можна порівняти з іншими примірниками власного класу, тоObject не може вимагати, щоб він був частиною інтерфейсу.

Джошуа Блох використовує ключові слова "природне впорядкування", коли пояснює, чому клас може хотіти реалізувати Comparable. Не кожен клас має природне впорядкування, як я згадував у своїх прикладах вище, тому не кожен клас повинен реалізовувати, Comparableа також не повинен Objectмати compareToметод.

... compareToметод не оголошено в Object. ... Він схожий за характером Objectз equalsметодом, за винятком того, що дозволяє порівняти замовлення на додаток до простих порівнянь рівності, і він є загальним. Реалізуючи Comparable, клас вказує, що його екземпляри мають природне впорядкування .

_{^{Ефективна Java, друге видання : Джошуа Блох. Пункт 12, стор. 62. Еліпси видаляють посилання на інші глави та приклади коду.}}

Для випадків , коли ви дійсно хочете , щоб накласти впорядкування на не- Comparableкласу , який не має природний порядок, ви завжди можете поставити Comparatorекземпляр для допомоги розбирайтеся.

У ПСБ §4.3.2 визначає, який classоб'єкт в такий спосіб:

4.3.2. Об'єкт класу

Клас Object- це суперклас (§8.1.4) усіх інших класів.

Усі типи класів і масивів успадковують (§ 8.4.8) методи класу Object, які узагальнені так:

• Метод cloneвикористовується для створення дубліката об'єкта.

• Метод equalsвизначає поняття об’єктної рівності, яке базується на значенні, а не посиланні, порівнянні.

• Метод finalizeзапускається безпосередньо перед знищенням об'єкта (§12.6).

• Метод getClassповертає об'єкт Class, який представляє клас об'єкта.

• А ClassОб'єкт існує для кожного посилального типу. Він може бути використаний, наприклад, для виявлення повноцінного імені класу, його членів, його безпосереднього суперкласу та будь-яких інтерфейсів, які він реалізує.

  Тип виразу виклику методу - getClassце те, Class<? extends |T|>де Tшукається клас чи інтерфейс (§15.12.1)getClass .

  Метод класу, який оголошується synchronized(§ 8.4.3.6), синхронізується на моніторі, пов’язаному з об'єктом Class класу.

• Метод hashCodeдуже корисний разом із методом, рівним, у хешшлях, таких як java.util.Hashmap.

• Методи wait, notifyі notifyAllвикористовуються в паралельному програмуванні з використанням ниток (§17.2).

• Метод toStringповертає String представлення об'єкта.

Отже, це equalsє, Objectале compareToзнаходиться в окремому інтерфейсі. Я б міркував, що вони хотіли зберегти Objectякомога менше. Вони, напевно, подумали, що майже все Objects буде потрібно equalsі hashCode(що насправді є лише формою перевірки рівності), але не всі об'єкти повинні мати концепцію впорядкування , для чого compareToвикористовується.

Окрім відмінної відповіді Сніговика, пам’ятайте, що Comparableце був загальний інтерфейс вже давно. Тип не реалізує compareTo(object), він реалізує compareTo(T)там, де Tє власний тип. Це неможливо реалізувати object, оскільки objectвін не знає класу, який буде походити з нього.

objectможна було б визначити compareTo(object)метод, але це дозволило б не лише те, що вказує Сніговик, порівняння між двома ArrayList<T>або між двома Thread, але навіть порівняння між a ArrayList<T>і a Thread. Це ще більш безглуздо.

Припустимо, у мене є дві посилання на об'єкт: X ідентифікує примірник Stringвмісту вмісту "Джордж"; Y ідентифікує примірник Pointкоординат [12,34]. Розглянемо наступні два питання:

• Чи ідентифікують X і Y еквівалентні об'єкти?

• Чи повинен X сортувати до, після або еквівалентний Y?

Той факт, що X і Y ідентифікують випадки споріднених типів, не створює жодних проблем при розгляді першого питання. Об'єкти можна вважати еквівалентними лише у тому випадку, якщо їх типи мають спільну базу, яка визначає їх як еквівалентні; оскільки Stringі Pointне мають такої бази (єдиний їх загальний тип бази розглядає всі окремі об'єкти як нееквівалентні), відповідь просто "ні".

Той факт, що типи не пов'язані між собою, створює величезну проблему щодо другого питання. Деякі типи визначають відносини впорядкування між їхніми примірниками, а деякі відносини впорядкування можуть навіть поширюватися на кілька типів [наприклад, це можна було б визначити BigIntegerі BigDecimalвизначити методи порівняння, які дозволяли б класифікувати екземпляри будь-якого типу відносно випадків іншого], але загалом неможливо взяти два довільні екземпляри і запитати "Чи слід X сортувати до, після або еквівалентно Y" та отримати загальне впорядкування. Можна було б запитати "Чи слід X сортувати до, після, еквівалентного чи невизначеного відносно Y", якщо об'єкти повинні були повідомити про послідовне впорядкування, але не загальнеОдин, але більшість алгоритмів сортування вимагає загального замовлення. Таким чином, навіть якщо всі об'єкти могли реалізувати compareToметод, якщо "unranked" був дійсним поверненням, такий метод був би недостатньо корисним для обгрунтування його існування.