Methode Arrays.sort(Object[] arr)

[igor99]

Hallo allerseits!

Die Methode public static void sort(Object[] a) aus der Klasse java.util.Arrays sortiert das übergebene Array von Objekten. Dazu ist allerdings nötig, dass die natürliche Sortierordnung definiert ist (die Mutterklasse von Objekten im Array muss die Schnittstelle Comparable implementieren). Meine Frage ist: Wieso hat man den Datentyp Object[] genommen? Wäre Comparable[] nicht sinnvoller gewesen? Gibt es dafür nachvollziebare Gründe?

Danke

 

[Tobias]

Ich vermute eine Nachlässigkeit (Unachtsamkeit) des Programmierers als Ursache. Eine Methode, die nur mit Comparable funktioniert, braucht keine Objects annehmen...

mpG
Tobias

 

[sliwalker]

Hi,

Comparable ist nur ein Interface und keine Klasse.
Object ist eine Klasse, von der alle anderen (zumindest alle nicht primitiven) Datentypen erben.
Sprich alles ist kompatibel zu Object. So kann man sich leicht aus dem Object wieder den Typ casten den man braucht.

greetz
SLi

 

[Guest]

So kann man sich leicht aus dem Object wieder den Typ casten den man braucht.

Ich habe die Implementierung angeschaut und habe keine Codezeile gefunden, welche mit Comparable nicht funktionieren würde.

Methode

public static void sort(Object[] a) {
        Object[] aux = (Object[])a.clone();
        mergeSort(aux, a, 0, a.length, 0);
    }

kann durch die Methode

public static void sort(Comparable[] a) {
        Object[] aux = (Object[])a.clone();
        mergeSort(aux, a, 0, a.length, 0);
    }

ersetzt werden. Auch die Methode mergeSort würde mit Comparable funktionieren (wenigstens nach der Meinung des Compilers, denn ausgeführt habe ich es nicht).

Habe ich da etwas übersehen? Oder, handelt es sich tatsächlich um die Nachlässigkeit des Programmierers?

Danke

 

[bygones]

scheint echt ein fehler der programmierer zu sein. Im sortiercode wird dann jedes Object zu einem Comparable gecastet. Wären die Objekte nicht vom Typ Comparable, so fliegt die methode logischerweise einem um die ohren....

Logischer wäre tatsächlich von anfang an Comparable zu verlangen !

 

[Roar]

und was ist wenn man als programmierer nur Objects zur verfügung hat, woher auch immer? ob man im eigenen code zu Comparable castet oder sort() das machen lässt kommt ja das gleiche raus, und letzteres is doch angenehmer...

 

[bygones]

aber es ist nicht sicher... würde die Methode Comparable verlangen, kann man sich sicher sein, dass auch sortiert wird... für mich stellt das einfach ein risiko da...

 

[sliwalker]

aber es ist nicht sicher... würde die Methode Comparable verlangen, kann man sich sicher sein, dass auch sortiert wird... für mich stellt das einfach ein risiko da...

Seh ich anders. Denn schließlich

Die Methode public static void sort(Object[] a) aus der Klasse java.util.Arrays sortiert das übergebene Array von Objekten. Dazu ist allerdings nötig, dass die natürliche Sortierordnung definiert ist (die Mutterklasse von Objekten im Array muss die Schnittstelle Comparable implementieren).

und deshalb kann man sich sicher sein. Darum unterstütz ich Roars Ansicht.

greetz
SLi

 

[bygones]

nein - falsch !

da Object verlangt wird kann man ohne Probleme eine beliebige Klasse reinstecken, die rein gar nix mit Comparable zu tun hat. Folge ist, die MEthode fliegt einem um die Ohren.

Würde die Methode sort gleich ein COmparable[] verlangen, so könnte ich gar nicht meine beliebige Klasse reinstecken und wäre somit sicher, dass die Methode erflogreich zu ende läuft

dein zitat widerspricht mir auch nicht im geringsten

(die Mutterklasse von Objekten im Array muss die Schnittstelle Comparable implementieren).

genau - die Objekte im Array MÜSSEN Comparable implementieren, damit es läuft - also warum nicht gleich in der Methode so festlegen ?!

 

[sliwalker]

Hi,

ich will Dir gern glauben, wenn ich es verstanden habe.
Dazu müsste ich aber noch folgendes loswerden:

sort() verlangt ein Array vom Typ Object.
Ich habe es jetzt so verstanden, dass das Array ruhig vom Typ Object sein kann, das ist ja völlig wurscht. Nur die einzelnen Elemente, die ja auch vom Typ Object sind, müssen von einer Klasse abgeleitet sein, die Comparable implementiert. Damit haben die Objekte im Array auch alle den Typ Comparable.
So ist es doch wenn man Interfaces implementiert!?

Jetzt weiß ich nicht genau, ob damit gleichzeitig auch das gesamte Array vom Typ Comparable ist. Aber ich sehe nicht, warum Du meinst, dass man was x-beliebiges reinpacken kann.

greetz
SLi

 

[bygones]

der Array ist immer vom Typ seiner Elemente, d.h. Comparable[] ist ein Array von Comparable elementen.

Stell dir vor du hast folgende Klasse:

public class MyClass {
  private String name;
  private int number;
  private List<String> content;
 

 //... irgendwelche Methoden
}

das ist nun meine xbeliebige Klasse, diese Klasse ist auch automatisch Object, d.h. ich kann mit dieser Klasse die sort Methode aufrufen

MyClass[] derArray = ....;
Arrays.sort(derArray);

der compiler meckert nicht, da er laut deklaration ein Object[] verlangt... die Methode fliegt mir aber um die Ohren, da MyClass nicht das Interface Comparable implementiert und somit der cast nach Comparable in der Methode sort nicht klappt.

Würde die Definition von sort explizit Comparable[] verlangen (klar, bei der mit einem Comparator ist dies obsolet), so würde schon der Compiler bei dem Aufruf oben meckern....

 

[Bleiglanz]

Würde die Definition von sort explizit Comparable[] verlangen (klar, bei der mit einem Comparator ist dies obsolet), so würde schon der Compiler bei dem Aufruf oben meckern...

In den meisten Fällen kommt das Array doch als irgendwas anderes daher, sagen wir

Person[]  personen;

und den dann fälligen Cast

Comparable[] foo = (Comparable[]) personen;

prüft der Compiler eh nicht elementweise, es würde also nur eine Zeile mehr Code erfordern der keinerlei Vorteile für die Typsicherheit bringt

vielleicht ham die auch das irgendwann mal übersehen, aber als teil der API kann man das jetzt nicht mehr ändern ohne exisiterenden Code ungültig zu machen

 

[bygones]

wenn die Methode sort einen Comparable[] als Parameter definieren würde, so bräuchte man in der methode überhaupt keinen cast. In der Methode wird nicht der array gecastet, sondern jedes element.

Durch das ändern würde man doch keinen existierenden Code ungütlig machen ?! es geht doch nur darum, das entsprechende Interface zu nehmen ....

 

[Bleiglanz]

"in" der Methode nicht, aber draussen? in

sort(Comparable[] arr)

könnte man doch (ohne cast) kein Object[] reinstecken?

 

[bygones]

klar, aber was für einen sinn macht es einen Object[] reinzustecken ? ich benötige zum sortieren eine definierte Ordnung, die ich bei einem Object[] möglicherweise gar nicht habe,.....

 

[Bleiglanz]

ja, es wäre sinnvoll wenn man "die Clients" zwingen würde, vor jedem Aufruf von sort(..) den cast

Comparable[] foo = (Comparable[]) personen;

explizit durchzuführen.

Aber der Compiler prüft ja an der Stelle gar nicht, ob Person das Interface überhaupt implementiert, von daher ist das IMHO von beschränktem Nutzen - auch wenns aus "Hygienegründen" schon so gemacht werden sollte

 

[Illuvatar]

Wie Bleiglanz sagte, wegen der Abwärtskompatibilität kann man das nicht mehr einfach ändern. Aber es wäre ja dennoch möglich, zusätzlich eine Methode sort(Comparable[]) einzubauen, und die alte deprecated zu machen.

Btw: Sun-Leute, lest den Thread hier

 

[bygones]

wenn ich die Klasse Person habe, die das Interface implementiert, so kann ich, wenn die Methodendefinition Comparable vorsieht, mein Person[] ohne Probleme übergeben. Würde sie es nicht tun, so müsste der Compiler meckern, wenn ich einfach Person[] übergebe....

daher ist doch ein cast unnötig, wenn meine Klasse das interface implementiert....

mhm - oder meckert da nicht der compiler sondern nur eclipse ?!

 

[Guest]

Es ist der compiler.

 

[Bleiglanz]

tatsächlich...es muss sich wohl um Faulheit handeln

die andere Sort-Methode

    public static <T> void sort(T[] a, Comparator<? super T> c) {
	T[] aux = (T[])a.clone();
        if (c==null)
            mergeSort(aux, a, 0, a.length, 0); // hier casten?
        else
            mergeSort(aux, a, 0, a.length, 0, c);
    }

delegiert nämlich einfach, wenn der Comparator null ist

und genau an der Stelle wäre der erzwungene cast ungeprüft, aber trotzdem: der Aufrufer würde die ohnehin fliegende Exception nur früher bekommen

offensichtlich ein echter Design-Fehler...?