Dlaczego .compareTo () jest w interfejsie, podczas gdy .equals () jest w klasie w Javie?

Chcę wiedzieć, dlaczego .compareTo()jest w Comparableinterfejsie, podczas gdy metoda podobna .equalsjest w Objectklasie. Wydaje mi się arbitralne, dlaczego takiej metody .compareTo()nie ma już w Objectklasie.

Aby użyć .compareTo(), zaimplementuj Comparableinterfejs i zaimplementuj .compareTo()metodę do swoich celów. W przypadku .equals()metody po prostu przesłonisz metodę w swojej klasie, ponieważ wszystkie klasy dziedziczą od Objectklasy.

Moje pytanie brzmi: dlaczego metoda jest taka jak .compareTo()w interfejsie, który implementujesz, a nie w klasie takiej jak Object? Podobnie, dlaczego .equals()metoda Objectma zostać zaimplementowana w klasie, a nie w jakimś interfejsie?

Nie wszystkie obiekty można porównać, ale wszystkie obiekty można sprawdzić pod kątem równości. Jeśli nic więcej, można sprawdzić, czy dwa obiekty istnieją w tym samym miejscu w pamięci (równość odniesienia).

Co to znaczy compareTo()na dwóch Threadobiektach? W jaki sposób jeden wątek jest „większy niż” inny? Jak porównać dwa ArrayList<T>s?

ObjectUmowa ma zastosowanie do wszystkich klas Java. Jeśli nawet jednej klasy nie można porównać do innych instancji własnej klasy, Objectnie może wymagać, aby była częścią interfejsu.

Joshua Bloch używa słów kluczowych „porządek naturalny”, wyjaśniając, dlaczego klasa może chcieć zaimplementować Comparable. Nie każda klasa ma naturalne uporządkowanie, jak wspomniałem w moich przykładach powyżej, więc nie każda klasa powinna implementować Comparableani nie powinna Objectmieć tej compareTometody.

... compareTometoda nie jest zadeklarowana w Object. ... Jest on podobny w charakterze do Object„s equalsmetody, oprócz tego, że pozwala na porównanie rzędu oprócz prostych porównań równości i jest rodzajowy. Poprzez implementację Comparableklasa wskazuje, że jej instancje mają naturalną kolejność .

_{^{Effective Java, Second Edition : Joshua Bloch. Punkt 12, strona 62. Elipsy usuwają odniesienia do innych rozdziałów i przykładów kodu.}}

W przypadkach, gdzie nie chcą narzucić kolejność na niebędącego Comparableklasy, które nie mają naturalną kolejność, zawsze można dostarczyć Comparatorinstancji to rodzaj pomocy.

W JLS §4.3.2 definiuje classobiekt w następujący sposób:

4.3.2 Obiekt klasy

Klasa Objectjest nadklasą (§ 8.1.4) wszystkich innych klas.

Wszystkie typy klas i tablic dziedziczą (§8.4.8) metody klas Object, które podsumowano w następujący sposób:

• Metoda clonesłuży do utworzenia duplikatu obiektu.

• Metoda equalsdefiniuje pojęcie równości obiektu, które opiera się na porównaniu wartości, a nie odniesienia.

• Metodę finalizetę uruchamia się tuż przed zniszczeniem obiektu (§12.6).

• Metoda getClasszwraca obiekt klasy reprezentujący klasę obiektu.

• Dla Classkażdego typu odwołania istnieje obiekt. Można go na przykład użyć do odkrycia w pełni kwalifikowanej nazwy klasy, jej członków, jej bezpośredniej nadklasy i wszelkich interfejsów, które implementuje.

  Typ wyrażenia wywołania metody getClassto, Class<? extends |T|>gdzie Tjest szukana klasa lub interfejs (§15.12.1) getClass.

  Zadeklarowana metoda klasy synchronized(§ 8.4.3.6) synchronizuje się na monitorze powiązanym z obiektem klasy klasy.

• Metoda ta hashCodejest bardzo przydatna, podobnie jak metoda równa się, w tablicach skrótów, takich jak java.util.Hashmap.

• Metody wait, notifyi notifyAllstosowane są w równoległych nitek programowania, za pomocą (§17.2).

• Metoda toStringzwraca ciąg reprezentujący obiekt.

Właśnie dlatego equalsjest w, Objectale compareTojest w osobnym interfejsie. Spekulowałbym, że chcieli ograniczyć Objectdo minimum. Prawdopodobnie doszli do wniosku, że prawie wszyscy Objects będą potrzebować equalsi hashCode(co jest tak naprawdę tylko formą testowania równości), ale nie wszystkie obiekty będą musiały mieć pojęcie uporządkowania , do czego się compareToto stosuje.

Oprócz doskonałej odpowiedzi Bałwana pamiętaj, że Comparableod dawna jest to ogólny interfejs. Typ nie implementuje compareTo(object), implementuje compareTo(T)gdzie Tjest swój własny typ. Nie można tego zaimplementować object, ponieważ objectnie zna klasy, która będzie z niego wyprowadzona.

objectmógł zdefiniować compareTo(object)metodę, ale pozwoliłoby to nie tylko na to, co wskazuje Snowman, porównanie dwóch ArrayList<T>s lub dwóch Threads, ale nawet porównanie między ArrayList<T>a a Thread. To jeszcze bardziej bezsensowne.

Załóżmy, że mam dwa odwołania do obiektów: X identyfikuje instancję Stringprzechowywania zawartości „George”; Y identyfikuje przykład Pointtrzymania współrzędnych [12,34]. Rozważ następujące dwa pytania:

• Czy X i Y identyfikują równoważne obiekty?

• Czy X powinien sortować przed, po, czy może być równoważny Y?

Fakt, że X i Y identyfikują przypadki niepowiązanych typów, nie stanowi żadnego problemu przy rozważaniu pierwszego pytania. Obiekty można uznać za równoważne tylko wtedy, gdy ich typy mają wspólną bazę, która określa je jako równoważne; ponieważ Stringi Pointnie mają takiej bazy (ich jedyny wspólny typ bazy uznaje wszystkie odrębne obiekty za równoważne) odpowiedź brzmi po prostu „nie”.

Fakt, że typy nie są ze sobą powiązane, stanowi jednak ogromny problem w odniesieniu do drugiego pytania. Niektóre rodzaje definiować relacje zamawiania wśród swoich wystąpień, a niektóre relacje Zamawiający może nawet rozciągać na wiele typów [np byłoby możliwe BigIntegeri BigDecimalzdefiniowanie metod porównawczych, które pozwoliłyby wystąpienia dowolnego typu, aby zostać sklasyfikowanym w stosunku do wystąpień drugi], ale generalnie nie jest możliwe, aby wziąć dwie arbitralne instancje i zapytać „Czy X posortuje przed, po lub jako równoważnik Y” i uzyskać całkowite uporządkowanie. Można by zapytać „Czy X powinien sortować przed, po, równoważny lub nierankingowany względem Y”, czy obiekty muszą zgłaszać spójne uporządkowanie, ale nie całkowitejeden, ale większość algorytmów sortowania wymaga całkowitego uporządkowania. Zatem nawet jeśli wszystkie obiekty mogłyby zaimplementować compareTometodę, jeśli „nierankowany” był prawidłowym zwrotem, taka metoda nie byłaby na tyle użyteczna, aby uzasadnić jej istnienie.