Generics Tripel

[LeeSin]

Servus zusammen, ich habe zwei klassen und arbeite mit dem Comparable interface und dem Comparator und ich muss drei WErte vergleichen nach "größen so wie ich das verstanden habe". Doch verstehe ich nicht ganz wie ich das umsetzen soll und würde mich über ein paar Denkanstöße sehr freuen!

1. Klasse

public class Tripel<U, V, W> implements Comparable<Tripel<U, V, W>> {
    /**
     * instance variables
     */
    U u;
    V v;
    W w;

    /**
     * from comparable interface
     */
    @Override
    public int compareTo(Tripel<U, V, W> o) {
        return 0;
    }

    /**
     * Constructor
     *
     * @param first  parameter
     * @param second parameter
     * @param third  parameter
     */
    public Tripel(U first, V second, W third) {
        this.u = first;
        this.v = second;
        this.w = third;
    }

}

2.Klasse

import java.util.Comparator;

public class TripelComparator<U, V, W> implements Comparator<Tripel<U, V, W>> {

    /**
     * compare from comparator and can equal objects from Tripel
     */
    @Override
    public int compare(Tripel<U, V, W> o1, Tripel<U, V, W> o2) {
        return 0;
    }

}

Ich soll u aufsteigend dann v aufsteigend dann w aufsteigend vergleichen. Denke mal das beduetet der größe nach? Mir fehlt irgendwie das wissen um das richtig mit den generics anzuwenden wie ich die Objekte logisch vergleiche. Im Netz konnte ich bisher nichts finden und Bücher haben mir leider auch nicht richtig geholfen.

Würde mich über anstöße freuen!

Liebe Grüße
Lee SIn

 

[mihe7]

Ist die Klasse Tripel so vorgegeben? Sollst Du die Klasse anpassen? Wenn ja, darfst Du die Deklaration ändern? Ich frage, weil das in der Form nur funktioniert, wenn Du den Typ von U, V und W überprüfst (U, V und W sind beliebige Typparameter. Beliebige Typen definieren aber keine Ordnung).

 

[Flown]

Wie sieht die Aufgabe wirklich aus?

Die Klassendeklaration würde sonst anders aussehen:

public class Tripel<U extends Comparable<? super U>, V extends Comparable<? super V>, W extends Comparable<? super W>> implements Comparable<Tripel<U, V, W>> {

 

[Gelöschtes Mitglied 9001]

Wie Flown schon schreibt, muss jeder der drei Typen comparable sein oder du implementierst für jeden einen Comparator. In dem Comparator, den du schon hast, gehst du dann wie folgt vor:
Vergleiche die U-Werte. Sind die nicht gleich -> entsprechend -1 oder 1 zurückliefern.
Vergleiche die V-Werte. Sind die nicht gleiche -> entsprechend -1 oder 1 zurückliefern.
Das gleiche mit W.

 

[Barista]

ich habe zwei klassen und arbeite mit dem Comparable interface und dem Comparator und ich muss drei WErte vergleichen

Diese drei Werte müssen sicher den gleichen Typ haben.
Du benötigst also nur einen Typ-Parameter.
Sieh Dir das mal bei Comparable an:

public class X extends Comparable<X> {
    
}

Abgesehen davon ist die Aufgabenstellung sehr verworren.
Sicher eine Hausaufgabe, der Sinn einer Hausaufgabe ist, sich mit dem Problem zu befassen, nicht die Aufgabe von Anderen lösen zu lassen.

 

[temi]

Diese drei Werte müssen sicher den gleichen Typ haben.
Du benötigst also nur einen Typ-Parameter.

Damit hast du vermutlich Recht! 👍

 

[mrBrown]

Diese drei Werte müssen sicher den gleichen Typ haben.
Du benötigst also nur einen Typ-Parameter.

Warum sollten die drei den gleichen Typ haben? Üblich wären eher unterschiedliche Typen.

 

[temi]

Warum sollten die drei den gleichen Typ haben? Üblich wären eher unterschiedliche Typen.

Ich würde ein Tripel als 3-Tupel von Elementen sehen, wobei die Elemente vom gleichen Typ sind. Siehst du das anders?

 

[mrBrown]

Ich würde ein Tripel als 3-Tupel von Elementen sehen, wobei die Elemente vom gleichen Typ sind. Siehst du das anders?

In nahezu jeder Implementierung ist das anders gelöst. Tupel (in Varianten von 1-X Elementen) ist meist 'beliebige Typen, feste Länge', und Listen 'gleiche Typen, beliebige Länge' (gleiche Typen natürlich nur in sprachen mit statischen Typen).
zB in Haskell, Typescript, Java mit zB javatuples, C#, Python, ...

 

[mihe7]

Ich würde ein Tripel als 3-Tupel von Elementen sehen, wobei die Elemente vom gleichen Typ sind. Siehst du das anders?

Das ist mathematisch schon anders.

 

[temi]

Da ich keine Ahnung davon habe, halte ich mich wohl besser raus

Ein

-Tupel ist eine Zusammenfassung von

mathematischen Objekten

So steht es in Wikipedia und als Laie hab ich das so interpretiert, wie oben geschrieben.

 

[mihe7]

So steht es in Wikipedia und als Laie hab ich das so interpretiert, wie oben geschrieben.

Das ist auch richtig, nur steht da nicht, dass die x1 bis xn aus der gleichen Menge sein müssen

D. h. das n-Tupel ist ein Element der Menge (X1 x X2 x ... x Xn)

 

[temi]

Das ist auch richtig, nur steht da nicht, dass die x1 bis xn aus der gleichen Menge sein müssen

Was müsste denn da stehen, wenn sie aus der gleichen Menge kommen müssen?

Ich habe das als Nichtmathematiker in Software übersetzt mit "n Elemente des Typs X".

 

[mihe7]

Was müsste denn da stehen, wenn sie aus der gleichen Menge kommen müssen?

Zum Beispiel:

 

[kneitzel]

Wenn der Typ gleich wäre, dann bräuchte man diese Klassen nicht unbedingt. Dann wäre ein einfaches Array prinzipiell auch nutzbar.

Erst bei der Implementation zusätzlicher Methoden würde ich einen Mehrwert durch Kapselung sehen ...

Das nur als Denkanreiz. Ich denke auch, dass da drei unterschiedliche Typen Sinn machen.

 

[mrBrown]

Wenn der Typ gleich wäre, dann bräuchte man diese Klassen nicht unbedingt. Dann wäre ein einfaches Array prinzipiell auch nutzbar.

Das Array hat aber keine fixe Länge, das ist schon ein ziemlicher Nachteil.

 

[kneitzel]

Nunja, du erzeugt ein Tripel: du hast 3 Werte.
Du erzeugt ein [3] und hast 3 Werte.

Das Problem ist nur, dass du bei einer Übergabe im Typ die 3 Werte nicht drin hast. Das hast du vermutlich gemeint.

Aber in der Struktur hast du die 3 Werte natürlich als fixe Länge.

 

[mrBrown]

Ja, bei int[] sind's beliebig viele Werte, bei Triple sind's immer genau 3.

 

[kneitzel]

Wibei beides recht blöde Krücken sind, die mir nicht gefallen. Man hat 3 Werte, die ja irgend etwas ausdrücken und die irgendwie zusammen gehören.

Ich saube mir mal etwas aus den Fingern: Autos, da speichert man ganz viele Daten... und nun gibt es da etwas wie getBeschleunigungswerte oder so. Und da kommen halt 3 Zahlen zurück: PS, Sekunden von 0 auf 100 und Sekunden von 100 auf 120.

Bei einem Tripel hat man dann bei der Abfrage so Dinge wie getFirst, getSecond, getThird oder was man da als universelle Getter nehmen möchte.

Da würde ich auf die Typprüfung lieber verzichten und Konstanten nutzen so dass ich da dann sowas wie ....[RESULT_INDEX_HORSEPOWER] und so hätte ... die fehlende Typkontrolle des Compilers muss natürlich entsprechend mit Unit Tests abgedeckt sein.... (nicht schön, klar!)

Aber das ist auch eine absolute Krücke. Wieso nicht einfach eine kleine Klasse dafür...oder Records von Java14 bieten sich an.

Dann habe ich die volle Typisierung + lesbaren Code.

Pair und Co haben zumindest in meinen Augen keinen wirklich großen Nutzen. (Die Aufgabe hier ist ja wohl auch mehr eine reine Übung)

Oder übersehe ich da etwas?

 

[Blender3D]

Ich würde ein Tripel als 3-Tupel von Elementen sehen, wobei die Elemente vom gleichen Typ sind. Siehst du das anders?

z.B. Ein Wahrscheinlichkeitsraum ist ein Tripel aus ( Ergebnismenge, Algebra, Wahrscheinlichkeitsmaß )
Allerdings ist bei unterschiedlichen Typen ein Größenvergleich im Allgemeinen nicht sinnvoll. Daher denken ich, dass in dem Beispiel der selbe Typ gemeint ist.

 

[thecain]

Wieso nicht? Es könnte ja sein <Groesse, Gewicht, Alter> dann entsprechend sortieren. Ich finde schon, dass das Sinn macht.

 

[mrBrown]

Wibei beides recht blöde Krücken sind, die mir nicht gefallen. Man hat 3 Werte, die ja irgend etwas ausdrücken und die irgendwie zusammen gehören.

Ja, in den meisten Fällen sind Domänen-spezifische Klassen passender als generische Tupel - für viele Fälle, in denen Tupel sinnvoll sind, gibts ja jetzt auch Records

 

[Barista]

Warum sollten die drei den gleichen Typ haben? Üblich wären eher unterschiedliche Typen.

Sieh dir mal eine Beispiel Implementierung von compareTo vor der Einführung von Generics an:

public int compareTo(Object other) {
    X otherX = (X) other;
   
    ... weiterer Code ...
}

Dies muss umkehrbar funktionieren (weiss jetzt nicht , ob das 'reflexiv' heisst, steht im Buch "Effective Java" von Josh Bloch):

a.compareTo( b ) == -( b.compareTo( a ) )

Demzufolge kann man nur mit dem gleichen Typ komperieren (jemand wird dieses komische Wort hassen).

 

[mrBrown]

Sieh dir mal eine Beispiel Implementierung von compareTo vor der Einführung von Generics an:

public int compareTo(Object other) {
    X otherX = (X) other;
  
    ... weiterer Code ...
}

Dies muss umkehrbar funktionieren (weiss jetzt nicht , ob das 'reflexiv' heisst, steht im Buch "Effective Java" von Josh Bloch):

a.compareTo( b ) == -( b.compareTo( a ) )

Demzufolge kann man nur mit dem gleichen Typ komperieren (jemand wird dieses komische Wort hassen).

Das ist mit Tripel<String, Integer, Double> problemlos möglich.

Man kann logischerweise nur zwei gleichen Typen vergleichen, aber der zu vergleichende Typ ist in diesem FallTripel<X, Y, Z>. X, Y und Z können aber unterschiedlich sein.

 

[Barista]

aber der zu vergleichende Typ ist in diesem FallTripel<X, Y, Z>

Ach so, aha.

 

[mrBrown]

Ach so, aha.

Ich bin mir nicht sicher, ob das ernstgemeinte Zustimmung sein soll, oder du anderer Meinung bist?

 

[Barista]

Ich bin mir nicht sicher, ob das ernstgemeinte Zustimmung sein soll, oder du anderer Meinung bist?

erstes