Best Practice Allgemeines Verhalten für ein Interface implementieren?

[newHoriz0n]

Hallo zusammen!

Das Problem:
Eine Klasse Wohnort implementiert unter anderem das Interface Haendler um Waren kaufen und verkaufen zu können. Wie ist die konventionelle Vorgehensweise um dem Haendler allgemeingültiges Verhalten beizubringen, das nicht nur für den Wohnort gedacht ist? Der Haendler selbst kann keine Klasse sein, da der Wohnort bereits von Ort erbt ...

Würdet ihr den Haendler zu einem eigenen Objekt in Wohnort machen?

Danke für eure Tipps!

 

[mrBrown]

Auf jeden Fall klingt es nach ziemlichem Unsinn, Wohnort Händler implementieren zu lassen.

Aber um mehr zu sagen, bräuchte man mehr Infos.

 

[Thallius]

Seite wann kauft ein Wohnort etwas? Wenn überhaupt, dann kauft eine Person die dort wohnt etwas. Und dafür muss diese dann wirklich keinen Händler als Interface implementieren sondern diese Person hat Zugriff auf eine Händlerliste und sucht sich dort einen Händler aus bei dem sie bestellt.

Denkt doch einfach mal ein wenig Realitätsbezogen wenn ihr schon Objektorientiert programmiert.

 

[newHoriz0n]

Beim Programmieren geht es grundsätzlich erstmal darum, ein Modell der Realität zu entwerfen. Modelle erfordern immer eine gewisse Abweichung von der Realität da man die Realität nie zu 100% abbilden kann - alles andere ist Utopie. Die "Händlerliste" schießt für meine Zwecke leider etwas über das Ziel hinaus aber trotzdem danke für den Hinweis

Meine eigentliche Frage beantwortet es leider auch nicht wirklich Also nochmal etwas abstrakter:
Eine Klasse implementiert mehrere Interfaces um die Funktionalität zu modularisieren. Gleichzeitig würde ich gerne verschiedenes Verhalten für die Interfaces vorprogrammieren und das von den implementierenden Klassen direkt nutzen. Wie macht man das?

Danke

 

[mrBrown]

Beim Programmieren geht es grundsätzlich erstmal darum, ein Modell der Realität zu entwerfen. Modelle erfordern immer eine gewisse Abweichung von der Realität da man die Realität nie zu 100% abbilden kann - alles andere ist Utopie.

Ja - aber Unsinn muss man trotzdem nicht produzieren. Nah an der Realität hat schon Sinn - und in den meisten Fällen wird man eher abstrakter, nicht konkreter sodass ein Wohnhaus plötzlich ein Haendler ist.

Die "Händlerliste" schießt für meine Zwecke leider etwas über das Ziel hinaus aber trotzdem danke für den Hinweis

Was ist denn dein Ziel?

Eine Klasse implementiert mehrere Interfaces um die Funktionalität zu modularisieren. Gleichzeitig würde ich gerne verschiedenes Verhalten für die Interfaces vorprogrammieren und das von den implementierenden Klassen direkt nutzen. Wie macht man das?

Möglich ist das nur mit default-Methoden.
In den meisten Fällen ist das aber Unsinn - eben weil mehrere, völlig unterschiedlich Interfaces in einer Klasse keinen Sinn haben.
Wenn du dein konkretes Problem einmal nennen würdest, könnte man besser was sagen

 

[TheWhiteShadow]

Java unterstützt diese modularisierung durch Interfaces nicht so toll wie z.B. Ruby, daher vergebe ich Schnittstellen lieber an spezialisierte Objekte in Attributen, als an das Objekt selbst.
In dem Beispiel ist Markt ein Interface für Marktplatz und Hafen. Beim Hafen braucht der Händler ein Schiff^^:

Markt markt = fremderOrt.getMarkt();
try {
meinOrt.getHaendler().kaufe(markt, Waren.FISCH, 3);
} catch (HaendlerHatKeinSchiffException e) {
// Der Markt ist ein Hafen
}

Wichtig ist hier, dass tatsächlich der Händler vom Markt kauft und nicht der eigene Ort vom Nachbarort. Außerdem kann Markt natürlich null sein, denn nicht jeder Ort hat einen Markt. Ein Markt kann ein Ort sein und würde "this" zurückgeben.
Solche Analogien sind nützlich um sich zu vergewissern, dass das Design sinnvoll ist. Ein solches Design ist einfacher erweiterbar, als eine abstrakte Speziallösung.
z.B. könnte man hier einen GroßHändler einführen, oder eine Handelsgilde, die die Händler aussendet um damit Multithreading zu unterstützen.

ich hoffe, das hilft dir bei der Ideeenfindung.

 

[tommysenf]

Eine Klasse implementiert mehrere Interfaces um die Funktionalität zu modularisieren. Gleichzeitig würde ich gerne verschiedenes Verhalten für die Interfaces vorprogrammieren und das von den implementierenden Klassen direkt nutzen. Wie macht man das?

Das löst man üblicherweise durch Delegation:

class Wohnort extends Ort implements Händler {

      private  Händler myHändler = new DefaultHändler();

      public void handeln() {
             myHändler.handeln();
      }
      ...
}

 

[mrBrown]

Das löst man üblicherweise durch Delegation:

class Wohnort extends Ort implements Händler {

      private  Händler myHändler = new DefaultHändler();

      public void handeln() {
             myHändler.handeln();
      }
      ...
}

Das bleibt damit aber Unsinn, warum sollte Ei Ort ein Händler sein?