Interface Generics: prüfen ob Interface deklariert wird

[Bernd Hohmann]

public class ObjectCache<V> {
   public int add(V value)  { ...}

   public void sort() {
       if ( V implements Compareable ) 
          quicksortCompareable();
          return;
       if ( V implements Comparator )
          quicksortComparator
          return;
       // jetzt machen wir dicke backen....
 
   }
}

Sprich: ich muss feststelle, ob mein Generics "V" nun Comperable oder Comparator implementiert.

Wie mach ich das am klügsten und vorallem mit möglicht wenig Kosten?

Bernd

 

[Noctarius]

Du kannst nur die Instanz also value auf eine Implementierung testen.

 

[Bernd Hohmann]

Du kannst nur die Instanz also value auf eine Implementierung testen.

V value = null;
if (value instanceof Comparator) {

geht also? Compiler meckert nicht.

Bernd

 

[Landei]

Ich glaube, das nützt dir hier nichts. Wenn V Comparable ist, kannst du V-Instanzen vergleichen. Wenn V ein Comparator<U> ist, kannst du damit U-Instanzen vergleichen, nicht V-Instanzen.

Schau dir mal TreeMap an: Da muss man den Comparator (so man nicht Comparable verwenden will) im Konstrukur übergeben, und der hat den Typ Comparator<V>, und nicht V.

 

[Bernd Hohmann]

Ich glaube, das nützt dir hier nichts. Wenn V Comparable ist, kannst du V-Instanzen vergleichen. Wenn V ein Comparator<U> ist, kannst du damit U-Instanzen vergleichen, nicht V-Instanzen.

Das ist ja genau das, was ich erreichen will: Wenn das zu speichernde Objekt im ObjectCache "Comparable" implementiert, dann wird auch mit einer Methode sortiert die "Comparable" nutzt. Das geht ganz Prima solange viele kleine Objekte abgespeichert werden.

Dumm wird es, wenn die Objekte grösser werden (also so 10-50MB per Stück). Hier muss bei "Comparable" jedesmal das Objekt komplett von der Platte gelesen und deserialisiert werden um dessen "compareTo(...)" aufzurufen.

Daher mache ich es mir recht einfach: die ".add(value)" Methode wird nochmal mit einem ".add(value, key)" geschrieben und als "key" muss der zukünftige Vergleichswert übergeben werden.

Implementiert "value" dann Comparator sortiere ich nur "key" statt des serialisierten "value".

Im derzeitigen Szenario denke ich mal, dass die Sortierung von 300 Objekten (ca. 20GB Daten) übers Netz statt 18min nur noch <1 Sekunden dauert *fg*

Bernd

 

[Landei]

Nochmal ganz langsam: Wenn V ein Comparator ist, kannst du damit keine Vs vergleichen. Und was das für ein Comparator genau ist, bekommst du zur Laufzeit nicht mehr raus (type erasure).

 

[Bernd Hohmann]

Nochmal ganz langsam: Wenn V ein Comparator ist, kannst du damit keine Vs vergleichen. Und was das für ein Comparator genau ist, bekommst du zur Laufzeit nicht mehr raus (type erasure).

Ja eben doch gemäss vom Rezept von Nocatrius: "Du kannst nur die Instanz also value auf eine Implementierung testen."

Ich ziehe mir eine (beliebig passende) deserialisierte Instanz von "V" und gut ist - es sei denn, Du sprichst ein Problem an was mich übermorgen (also wenn ich es fertig machen will) derbe treffen wird.

	public void sort() throws IOException {
		checkopen();
		if (size() == 0) return;

		V value = get(0);
		if (value instanceof Comparator) {
			qsort_comparator(0, size() - 1);
			return;
		}
		if (value instanceof Comparable<?>) {
			qsort_comparable(0, size() - 1); // Todo: qsort_comparable() fertig implementieren
			return;
		}
		throw new InvalidObjectException("Cannot sort: <V> does not implement Comparable or Comparator");
	}

Soweit bin ich schonmal ohne dass der Compiler meckert.

Bernd

 

[Noctarius]

Bitte ändere die Methodennamen nach Convention, das brennt so in den Augen, wir sind nicht bei C++

 

[Bernd Hohmann]

Bitte ändere die Methodennamen nach Convention, das brennt so in den Augen, wir sind nicht bei C++

Nicht C++ ? Mist - schon wieder die Sprache verwechselt

Bernd

 

[bygones]

Die Aussage Noctarius widerspricht nicht Landeis.

Noctarius sagte dass du nur die variablen testen kannst, nicht den Generischen parameter.

Landei sagt, dass dir der Vergleich ob die variable ein comparator ist nix bringt, weil sie nix sagt, was sie sortiert...

if (value instanceof Comparator) {
            qsort_comparator(0, size() - 1);
            return;
        }

nun weisst du das value ein Comparator ist, aber nicht was er sortiert. Er kann Strings sortieren, Integers oder was auch immer...

 

[Bernd Hohmann]

nun weisst du das value ein Comparator ist, aber nicht was er sortiert. Er kann Strings sortieren, Integers oder was auch immer...

Ok, das ist dann Sache der Implementation. Das wird vermutlich eh ziemlich dirty über Object abgewickelt werden - mal schauen.

Bernd

 

[Landei]

Du wirst dann gegen eine Mauer laufen, die da "Type Erasure" heißt. Das ist eine ganz prinzipielle Einschränkung, um die sich nur in sehr speziellen Fällen herumhacken lässt. Deshalb ja mein Rat, dich jetzt - auf konzeptioneller Ebene - damit zu beschäftigen.

 

[Marco13]

Mal was ganz gewagtes: Könnte sort nicht abstract sein, und es zwei verschiedene Implementierungen davon geben? Oder der Comparator im Konstruktor der Klasse gesetzt/festgelegt werden? (Ggf. mit einem default 'ComparableComparator', der beliebige Comparables vergleicht... schräg, dass es das nicht in der Standard-API gibt...)

 

[Bernd Hohmann]

Du wirst dann gegen eine Mauer laufen, die da "Type Erasure" heißt. Das ist eine ganz prinzipielle Einschränkung, um die sich nur in sehr speziellen Fällen herumhacken lässt. Deshalb ja mein Rat, dich jetzt - auf konzeptioneller Ebene - damit zu beschäftigen.

Mein Java-Decompiler sagt dazu:

public void sort() throws IOException {
    checkopen();
    if (size() == 0) return;

    Object localObject = get(0);
    if ((localObject instanceof Comparator)) {
      qsort_comparator(0, size() - 1);
      return;
    }
    if ((localObject instanceof Comparable)) {
      qsort_comparable(0, size() - 1);
      return;
    }
    throw new InvalidObjectException("Cannot sort: <V> does not implement Comparable or Comparator");
}

Bis jetzt sehe ich nicht, dass mir der Typ verloren gegangen ist - oder irre ich?

Bernd

 

[nillehammer]

Bis jetzt sehe ich nicht, dass mir der Typ verloren gegangen ist - oder irre ich?

Ja, Dir geht der generische Anteil der Interface-Definition flöten. Wenn du in Deinem Object-Cache verischiedene Implementierungen von Comparable (z.B. ein paar Strings und ein paar Integers) zusammen drinnen hast und diese dann mit deinem Alghoritmus per qsort_comparable sortieren willst, dann versucht Dein Programm, Strings mit Integers zu comparen und das dürfte mit einer ClassCast-Exception quittiert werden. Wenn du natürlich sicher stellen kannst, dass nur Objekte, die mutually Comparable sind, in Deinem Cache liegen, dann ist das für Dich kein Problem.

 

[Bernd Hohmann]

Ok, verstanden - nein, im Cache liegt immer nur eine Sorte von Compareable/Comparator.

Ich wüsste jetzt auch nicht, wie eine Sortierung laufen sollte wenn da alles Mögliche gemischt drin liegt.

Bernd

 

[nillehammer]

Ich wüsste jetzt auch nicht, wie eine Sortierung laufen sollte wenn da alles Mögliche gemischt drin liegt.

Ich auch nicht und Java auch nicht. Deswegen ist Comparable ja generisch und schmeißt ClassCastExceptions, wenn alles Mögliche gemischt ist

 

[JohannisderKaeufer]

class Auto implements Comparable<Fahrzeug> {

int ps;

public int compareTo(Fahrzeug o){
    return (ps - o.ps < 0)? -1:1;
}

public int compareTo(Bus b){
  return -1;
}

public int compareTo(Motorrad m){
  return 1;
}
}

Sowas sollte sich doch zumindest compilieren lassen und in einer Collection<Fahrzeug> verwenden lassen. Damit würden dann Motorräder ganz vorne und Busse ganz hinten in der Liste auftauchen.

 

[nillehammer]

@JohannisderKaeufer: Schon klar, über sowas waren wir in der Diskussion aber schon hinaus. Mit "alles mögliche gemischt" war wirklich alles Mögliche gemeint und explizit Objekte, die eben nicht wechselseitig Comparable sind.