Problem: mehrere Interfaces definieren equals() neu

[-frank]

angenommen ich habe ein Interface A, das definiert, dass A Objekte als equal gelten sollen, wenn eine bestimmte Variable a equal ist.
dann habe ich ein weiteres Interface B (oder eine abstrakte Klasse B), die definiert, dass B Objekte gleich sein sollen, wenn deren Variable b gleich ist.
(A und B haben nichts miteinander zu tun)

okay, und nun habe ich eine Klasse C, die A und B implementiert/erweitert. nun entsteht natürlich das problem, wie die equals methode zu implementieren ist.

frage: bin ich hier schon an einem punkt, wo einfach das design/konzept falsch bzw fehleranfällig ist? also sollte man das einfach nicht so machen? das problem ist, dass A und B wie gesagt nicht wirklich etwas miteinander zu tun haben und ich - um bequem mit Listen von A und B arbeiten zu können - equals()/hashCode() überschrieben habe.

wenn ich nun aber das Interface A (oder B) dahingehend ändere, dass die equals Methode equalsA (oder equalsB) heißt, dann stört das vielleicht andere entwickler, die nur mit A (oder B) zu tun haben und nicht mit beiden Klassen.

ist es generell nicht ratsam, in Interfaces equals/hashCode neu zu definieren?

 

[HLX]

In Interfaces können Methoden lediglich deklariert werden. Eine implementierung ist nicht möglich. Somit kann es hier nicht zu Konflikten kommen.

 

[-frank]

In Interfaces können Methoden lediglich deklariert werden. Eine implementierung ist nicht möglich.

das ist mir bewusst. deswegen habe ich von "definieren" gesprochen. was ich meinte, ist, dass in der Javadoc-Dokumentation des Interfaces angegeben wird, dass Instanzen von A als gleich gelten sollen, wenn die Methode getXY() das gleiche Objekt liefert.
natürlich muss dies erst von anderen Klassen implementiert werden, aber im Interface wird es eben so festgelegt.

 

[HLX]

Es ist nicht Sinn des Interfaces die Implementierung vorwegzunehmen. Vielmehr ist die Implementierung einer Eigenschaft der konkreten Klasse zu überlassen. So hast du die Möglichkeit für verschiedene Objekte eine Methode aufzurufen und die nach deren Regeln abarbeiten zu lassen.

Ein kleines Beispiel:

Die beiden Menschen "HLX" und "-frank" sind von der Klasse AbstraktMensch abgeleitet und erben somit die Eigenschaften der Menschen. Sie implementieren aber auch das Interface "IArbeiter". Das Interface IArbeiter deklariert eine Methode fahreZurArbeit(). Nun sind die Schritte (ins Auto Steigen, der Arbeitsweg etc.) in der konkreten Ausprägung von HLK und -frank zu implementieren, da dies Individualitäten sind

Nun kann eine Simulation "Tagesablauf" für alle IArbeiter die Methode "fahreZurArbeit()" aufrufen und jede Ausprägung tut dies gemäß ihrer Implementierung. Eine vorherige Festlegung von Details macht keinen Sinn.

 

[-frank]

interface Mensch {
    void setBeruf(Beruf beruf);

    Beruf getBeruf();
}

interface Handwerker {
    
    /**
       *  Beruf sollte vom Typ HandwerklicherBeruf sein!
       */ 
    void setBeruf(Beruf beruf);

    HandwerklicherBeruf getBeruf();
}

class HandwerkerImplementierung implements Handwerker {

        void setBeruf(Beruf beruf) {
        if (beruf instanceof HandwerklicherBeruf) {
            this.beruf = beruf;
        } else {
            // exception!!
        }
}

ich kann im interface handwerker in der methode setBeruf nicht den handwerklichen beruf veraussetzen kann, daher tue ich es nur in getBeruf UND auch im kommentar von setBeruf. damit nehme ich ich natürlich die implementierung vorweg, aber entwickler, die andere implementierungen von Handwerker als meine HandwerkerImplementierung bereitstellen, sollen ja auch darauf hingewiesen werden, dass der Beruf diesen bestimmten Typ haben muss. wie soll ich sonst Kovarianz (bei den Argumenttypen) in Java implementieren?

und bei equals() ist es eben ein besonderes problem. angenommen jeder mensch in meinem beispiel hat eine sozialversicherungsnummer. und diese ist eindeutig. --> ein mensch gilt als "gleich", wenn er dieselbe sozialversicherungsnummer hat. wenn ich dies in HandwerkerImplementierung so dokumentiere ist es nett, aber ein entwickler, der eine Mensch-Klasse implementiert, wird sich nur das Interface Mensch ansehen. also muss dort definiert werden, wie die equals Methode aussehen soll.
(okay, das beispiel mit equals ist ein besonderes, weil es schon von Object implementiert wird.)

 

[HLX]

Dein Beispiel zeigt genau das Verständnisproblem. Wenn du ein Interface Handwerker hast, dann ist der Beruf am Interface Mensch überflüssig. Nicht jeder Mensch hat einen Beruf (Kinder...). Sammele Eigenschaften des Menschen (Körpergröße, Alter etc.) am Menschen und Berufliche Eigenschaften an einem Interface Beruf. Wenn der konkrete Mensch -frank einen Beruf hat, dann implementiert er einfach das Interface Beruf. Überall dort wo es gebraucht wird kann nun dieses Interface übergeben werden und die entsprechenden Methoden aufgerufen werden.

In deinem konkreten Fall sollte der Mensch ein Interface Sozialversicherungsnehmer implementieren. Dieses deklariert die Methoden getSozialversicherungsnummer() und setSozialversicherungsNummer(). Diese kannst du dann Vergleichen. Dazu übergibst du in einer beliebigen Klasse, in einer beliebigen Methode das Interface:

boolean vergleicheSozialversicherung(Sozialversicherungsnehmer a, Sozialversicherungsnehmer b) {
       return a.getSozialversicherungsNummer().equals(b.getSozialVersicherungsNummer();
}

jeder der nun das Interface Sozialversicherungsnehmer implementiert kann hier verarbeitet werden, ohne das man seine konkrete Ausprägung kennt.

 

[AlArenal]

Ist zwar etwas philosophisch,. aber macht es Sinn wenn eine Klasse Mensch und Beruf implementiert? Die Beziehung zwischen Mensch und Beruf sollte doch eine Has-a- und nicht eine Is-a-Beziehung sein. Ich BIN kein Beruf, ich HABE einen Beruf....

 

[-frank]

Dein Beispiel zeigt genau das Verständnisproblem. Wenn du ein Interface Handwerker hast, dann ist der Beruf am Interface Mensch überflüssig.

ich hatte zuerst ein anderes beispiel gewählt und vergessen "Mensch" in "Arbeiter" oder "ArbeitenderMensch" umzubenennen. JEDER Arbeiter soll einen Beruf haben. ein Handwerker aber soll einen handwerklichen Beruf haben.

In deinem konkreten Fall sollte der Mensch ein Interface Sozialversicherungsnehmer implementieren. Dieses deklariert die Methoden getSozialversicherungsnummer() und setSozialversicherungsNummer(). Diese kannst du dann Vergleichen. Dazu übergibst du in einer beliebigen Klasse, in einer beliebigen Methode das Interface:

boolean vergleicheSozialversicherung(Sozialversicherungsnehmer a, Sozialversicherungsnehmer b) {
       return a.getSozialversicherungsNummer().equals(b.getSozialVersicherungsNummer();
}

auf diese Art werde ich jetzt auch machen. zuvor lautete das ganze aber eben eher

boolean equals(Object object) {
    if (object instanceof Sozialversicherungsnehmer) {
        Sozialversicherungsnehmer versicherter = (Sozialversicherungsnehmer) object;
        return getSozialversicherungsNummer().equals(verscherter.getSozialVersicherungsNummer());
    }
    return false;
}

das ist sehr bequem, wenn man mit collections arbeitet.

Ist zwar etwas philosophisch,. aber macht es Sinn wenn eine Klasse Mensch und Beruf implementiert? Die Beziehung zwischen Mensch und Beruf sollte doch eine Has-a- und nicht eine Is-a-Beziehung sein. Ich BIN kein Beruf, ich HABE einen Beruf....

finde auch, dass das eher verwirrend ist.

 

[HLX]

Ist zwar etwas philosophisch,. aber macht es Sinn wenn eine Klasse Mensch und Beruf implementiert? Die Beziehung zwischen Mensch und Beruf sollte doch eine Has-a- und nicht eine Is-a-Beziehung sein. Ich BIN kein Beruf, ich HABE einen Beruf....

Korrekt. Formulierungsfehler von mir. Das Interface Beruf wäre natürlich oberbegriff für Berufe. Berufsinhaber o.ä. ist besser.

 

[Tobias]

Wie du deine equals-Methode implementierst, ist doch eine Frage, die darauf abzielt, welches Verhalten du letztlich erreichen willst. Wahrscheinlich reicht es schon, wenn du deiner equals sagst, meine Objekte sind gleich, wenn sowohl Variable a als auch Variable b gleich sind. Generell kann es aber ein Zeichen für schlechtes Design sein, wenn ich zwei Interfaces, die überhaupt nichts miteinander zu tun haben, in einer Klasse implementiere (Separation of Concerns). Überprüfe deinen Entwurf kritisch, überlege, ob das gewünschte Verhalten erreicht wird, wenn du bestimmte "Gleichheitsregeln", die die Erfordernisse beider Interfaces erfüllen, definierst, und gut ist.

mpG
Tobias

 

[-frank]

Wie du deine equals-Methode implementierst, ist doch eine Frage, die darauf abzielt, welches Verhalten du letztlich erreichen willst. Wahrscheinlich reicht es schon, wenn du deiner equals sagst, meine Objekte sind gleich, wenn sowohl Variable a als auch Variable b gleich sind.

leider nicht. wenn ich definiere, dass in C, welches A und B implementiert, a und b gleich sein müssen und dann zb in eine List<A> ein C objekt gebe, dann wird jenes vielleicht nicht gefunden wenn mit ich mit indexOf(..) suche. denn wenn es mit einem C-Objekte verglichen wird und a zwar gleich ist aber b nicht, dann gilt es nicht als gleich obwohl es im kontext der List<A> als gleich gelten sollte...

Generell kann es aber ein Zeichen für schlechtes Design sein, wenn ich zwei Interfaces, die überhaupt nichts miteinander zu tun haben, in einer Klasse implementiere (Separation of Concerns). Überprüfe deinen Entwurf kritisch, überlege, ob das gewünschte Verhalten erreicht wird, wenn du bestimmte "Gleichheitsregeln", die die Erfordernisse beider Interfaces erfüllen, definierst, und gut ist.

naja, B ist ein interface, dass man schnell mal auf ne Klasse "draufpackt". zb sowas wie ActionListener. also das ist denke ich schon in ordnung. das problem war wohl eher, dass ich B überhaupt die die equals methode überschreiben habe lassen - einfachs weils im anderen Kontext praktisch war - aber es hätte eigentlich klar sein müssen, dass dieses Interface von klassen implementiert werden wird, die sich nicht "leisten" können equals in der geforderten weise zu implementieren.

 

[Tobias]

Du könntest die "Vergleichen"-Logik in einen Comparator auslagern.

mpG
Tobias

 

[byte]

Naja, ein Comparator definiert eine Ordnung, also mehr als einfach ein Vergleich auf (Un-) Gleichheit der Objekte.

 

[bygones]

mhm mit der gefahr hin das problem missverstanden zu haben.

rein logisch ist es unsinnig ein Interface Mensch oder Handwerker zu haben.... Interfaces sagen aus WIE etwas sich verhaelt, wozu etwas in der Lage ist (serialisierbar, vergleichbar, beobachtbar und und und). Das was du aufzaehlst sind Entitys und diese gehoeren in Klassen.

Klasse Mensch und dann moeglicherweise eine abgeleitete Klasse Handwerker.

Interfaces hierzu zu verwenden ist nicht nur verwirrend, sondern falsch !

achja und entwickler etwas machen zu lassen in dem man es in die javadoc schreibt ist ebenso nicht sinnig, es beachtet keiner bzw ist nicht sicher... d.h. wenn etwas sein muss dann muss man es per code zwingen (handerwerker muessen handerwerkerberufe machen, also koennen sie nur HanderwerksBerufe annehmen) usw.

die konzeptionierung ist mir einfach absolut unschluessig....

 

[-frank]

mhm mit der gefahr hin das problem missverstanden zu haben.

rein logisch ist es unsinnig ein Interface Mensch oder Handwerker zu haben.... Interfaces sagen aus WIE etwas sich verhaelt, wozu etwas in der Lage ist (serialisierbar, vergleichbar, beobachtbar und und und). Das was du aufzaehlst sind Entitys und diese gehoeren in Klassen.

Klasse Mensch und dann moeglicherweise eine abgeleitete Klasse Handwerker.

Interfaces hierzu zu verwenden ist nicht nur verwirrend, sondern falsch !

das interface mensch definiert doch, wozu ein mensch in den lage ist. zb kann ein Mensch-Objekt auf die "Fragen" getName() oder "getBirthday() antworten. weiters kann ich einen Beruf setzen (setBeruf(Beruf)), etc. ein Mensch könnte auch verheiratet werden, etc.
zudem gibt es in java nur einfache vererbung. ein "extends Mensch" ist vielleicht nicht drin, während ein "implements Mensch" vielleicht ganz simpel ist.

achja und entwickler etwas machen zu lassen in dem man es in die javadoc schreibt ist ebenso nicht sinnig, es beachtet keiner bzw ist nicht sicher... d.h. wenn etwas sein muss dann muss man es per code zwingen (handerwerker muessen handerwerkerberufe machen, also koennen sie nur HanderwerksBerufe annehmen) usw.

in dem ich im Interface Handwerker getBeruf() einen Beruf vom Type HandwerklicherBeruf zurückgeben lasse, erzwinge ich es indirekt ohnehin. Es kann aber IMO nicht schaden, wenn ich es auch in der Doku der set-Methode erwähne. Erzwingen kann ich es dort ja nicht, weil es der Compiler nicht erlaubt.

aber generell verstehe ich nicht, warum ich in einem Interface nichts vorgeben kann (in der Doku). Nichts anderes tut ja zb auch Sun in der Java API. gutes Beispiel ist das Comparable interface. erzwungen wird da nur, dass es eine Methode compareTo(T object), die eine Zahl zurück gibt. alles weitere steht erst in der Doku.

 

[AlArenal]

mhm mit der gefahr hin das problem missverstanden zu haben.

rein logisch ist es unsinnig ein Interface Mensch oder Handwerker zu haben.... Interfaces sagen aus WIE etwas sich verhaelt, wozu etwas in der Lage ist (serialisierbar, vergleichbar, beobachtbar und und und). Das was du aufzaehlst sind Entitys und diese gehoeren in Klassen.

qed

TableModel, TreeModel, ActionListener, ...

 

[bygones]

mhm mit der gefahr hin das problem missverstanden zu haben.

rein logisch ist es unsinnig ein Interface Mensch oder Handwerker zu haben.... Interfaces sagen aus WIE etwas sich verhaelt, wozu etwas in der Lage ist (serialisierbar, vergleichbar, beobachtbar und und und). Das was du aufzaehlst sind Entitys und diese gehoeren in Klassen.

qed

TableModel, TreeModel, ActionListener, ... [/quote
ich habe 1. nicht behauptet dass sun hier miese ausnahmen macht, und 2. ja stimmt... gibt bekannte und richtige ausnahmen.

dennoch bleib ich dabei dass Mensch bzw Handerwerker als Interface eine falsche Konzeptionierung sind !

wozu gibt es dann deiner ansicht nach Abstrakte Klassen zb ?

aber generell verstehe ich nicht, warum ich in einem Interface nichts vorgeben kann (in der Doku). Nichts anderes tut ja zb auch Sun in der Java API. gutes Beispiel ist das Comparable interface. erzwungen wird da nur, dass es eine Methode compareTo(T object), die eine Zahl zurück gibt. alles weitere steht erst in der Doku.

falscher vergleich.

Sun sagt es gibt eine Methode die andere Klassen verwenden um z.b. sortieren zu koennen. Sortiert werden soll ein Objekt, egal was fuer eins, zurueckgegeben wird eine Zahl die sagt, ob der Parameter oder die aktuelle Instanz groesser bzw kleiner sind. Beides wird durch die Signatur der Methode vorgegeben, nicht durch die JavaDoc ! Es ist klar dass es einem um die Ohren haut wenn du in der compareTo methode den parameter zu einem anderen objekt castest als vorgesehen, daher gibt es 2 moeglichkeiten
1. du laesst das so bewusst geschehen und riskierst damit eine CastException
2. du zwingst die leute wirklich nur die Klassen benutzen zu koennen die vorhergesehen sind.

interface Handwerker {
   
    /**
       *  Beruf sollte vom Typ HandwerklicherBeruf sein!
       */
    void setBeruf(HandwerklicherBeruf beruf);

    HandwerklicherBeruf getBeruf();
}

was spricht denn gegen diese moeglichkeit ?

 

[-frank]

dennoch bleib ich dabei dass Mensch bzw Handerwerker als Interface eine falsche Konzeptionierung sind !

wozu gibt es dann deiner ansicht nach Abstrakte Klassen zb ?

abstrakte klassen sind nett, aber mehr als ein extends gibts eben nicht. was machst du, wenn du von mehreren abstrakten Klassen erben müsstest? es bleibeb eben nur interfaces, da es keine direkte merhfachvererbung gibt in java.

interface Handwerker {
   
    /**
       *  Beruf sollte vom Typ HandwerklicherBeruf sein!
       */
    void setBeruf(HandwerklicherBeruf beruf);

    HandwerklicherBeruf getBeruf();
}

was spricht denn gegen diese moeglichkeit ?

dagegen spricht, dass Handwerker "Arbeiter" erweitern soll. und dann erlaubt der Compiler die Einschränkung nicht mehr.

 

[HLX]

mhm mit der gefahr hin das problem missverstanden zu haben.

rein logisch ist es unsinnig ein Interface Mensch oder Handwerker zu haben.... Interfaces sagen aus WIE etwas sich verhaelt, wozu etwas in der Lage ist (serialisierbar, vergleichbar, beobachtbar und und und). Das was du aufzaehlst sind Entitys und diese gehoeren in Klassen

dennoch bleib ich dabei dass Mensch bzw Handerwerker als Interface eine falsche Konzeptionierung sind !

Das Interfaces nur aussagen WIE sich etwas verhält ist quatsch. Interfaces sind die einzige Möglichkeit der Mehrfachvererbung in Java. Wie abgeleitet wird hängt vom Kontext der Anwendung ab. In der Regel würde man Personen wohl per extends von Mensch ableiten. Manche Personen können dann noch das Interface Sozialversichungsnehmer implementieren. Dadurch kann man Code modularer halten, da die entsprechende Anstalt nicht die Menschen sondern nur den Sozialversicherungsnehmer kennen muss.

Generell entscheidet jedoch der Zweck und die Anforderungen der Anwendung bzw. das Fachkonzept wie das EDV-Konzept auszusehen hat. Daher pauschal auf falsche Konzeptionierung zu schließen ist nicht korrekt.

 

[bygones]

koennt sagen was ihr wollt, Interfaces fuer Mehrfachvererbung zu nehmen halte ich fuer falsch, auch wenn es die einzige moeglichkeit darstellt.

Vererbung ist durch die zusammenlagerung von gleichheiten stark, also dass man weiss das 2 oder mehrere Objekte sich gleich in bestimmten Ereignissen verhalten. und das geht ueber das interface nicht !

Ueber eine andere Konzeptionierung und moeglicherweise Role-Player Pattern oder sonstiges lassen sich schon vieles machen..

aber egal... tut was ihr nicht lassne koennt ;-)

 

[Wildcard]

koennt sagen was ihr wollt, Interfaces fuer Mehrfachvererbung zu nehmen halte ich fuer falsch, auch wenn es die einzige moeglichkeit darstellt.

Was ist daran falsch? Es handelt sich um eine 'verhält sich wie ein' Beziehung wenn man ein Interface implementiert.

 

[bygones]

koennt sagen was ihr wollt, Interfaces fuer Mehrfachvererbung zu nehmen halte ich fuer falsch, auch wenn es die einzige moeglichkeit darstellt.

Was ist daran falsch? Es handelt sich um eine 'verhält sich wie ein' Beziehung wenn man ein Interface implementiert.

oeh meine posts ganz lesen ;-) einfach den naechsten satz

 

[-frank]

koennt sagen was ihr wollt, Interfaces fuer Mehrfachvererbung zu nehmen halte ich fuer falsch, auch wenn es die einzige moeglichkeit darstellt.

Was ist daran falsch? Es handelt sich um eine 'verhält sich wie ein' Beziehung wenn man ein Interface implementiert.

oeh meine posts ganz lesen ;-) einfach den naechsten satz

du kommst völlig ohne mehrfachvererbung aus?

 

[Wildcard]

@dbac
Ich sehe nicht wie der nächste Satz deine Aussage relativiert.
Letztlich geht es darum das eine Methode ihren Kontrakt erfüllt, ob sie nun in einem Interface oder einer Superklasse definiert wurde ist nicht relevant.
Vom Konzept her ist implements und extends recht ähnlich und von den Eigenschaften nach aussen identisch.

 

[bygones]

du kommst völlig ohne mehrfachvererbung aus?

in all den jahren habe ich es geschafft immer eine andere loesung zu finden...

ansonsten... wie gesagt macht wie ihr es wollt - ist euch egal.