Der code smell beginnt beim instanceof…

[finzi]

Bin ich der einzige, dem es bei dem im Artikel angeführten Beispiel kalt den Rücken runterläuft? In meiner Erfahrungswelt deutet in objektorientiertem Code beinahe jegliche Verwendung von instanceof auf ein massives Defizit der Architektur hin – im Besonderen in switch-artigen Konstrukten.
Im konkreten Fall würde man wohl der jedem Tier eine print-Methode geben wollen, die dann entsprechend zu implementieren ist.

[Schard]

Für den Java-Fall hast du Recht. Allerdings würde ich es nicht pauschal auf objektorientierten Code erweitern. Beim objektorientiertem Arbeiten mit stark, aber dynamisch typisierenden Sprachen, wie z.B. Python, ist instanceof manchmal hilfreich.

[Lord Gamma]

Schard schrieb:
--------------------------------------------------------------------------------
> Für den Java-Fall hast du Recht. Allerdings würde ich es nicht pauschal auf
> objektorientierten Code erweitern. Beim objektorientiertem Arbeiten mit
> stark, aber dynamisch typisierenden Sprachen, wie z.B. Python, ist
> instanceof manchmal hilfreich.

Objektorientierter Code bedeutet in der Regel, dass Polymorphie so versteckt ist, dass man die Virtual Table nicht manuell pflegen muss.
Siehe auch [www.youtube.com]

[magslamenas]

Ich denke, das Beispiel war absichtlich stark vereinfacht gehalten. Spannender wird es wohl, wenn du aufgrund der Klasse des Objekts Aktionen ausführen möchtest, die das Objekt aufgrund der Architektur nicht kennt. Dann ist es auch deutlich von Vorteil, wenn der Compiler dich auf fehlende Optionen für neue Implementierungen des Interfaces hinweist.

[BLi8819]

Wenn ich an einer Stelle eine Logik brauche, wo ich anhand des Objekttyps bestimmte Dinge ausführen möchte, dann möchte ich diese Logik nicht zwangsläufig ins Interface oder in die Vererbungsh. verschieben.

[Das Osterschnabeltier]

finzi schrieb:
--------------------------------------------------------------------------------
> Bin ich der einzige, dem es bei dem im Artikel angeführten Beispiel kalt
> den Rücken runterläuft? In meiner Erfahrungswelt deutet in
> objektorientiertem Code beinahe jegliche Verwendung von instanceof auf ein
> massives Defizit der Architektur hin – im Besonderen in
> switch-artigen Konstrukten.
> Im konkreten Fall würde man wohl der jedem Tier eine print-Methode geben
> wollen, die dann entsprechend zu implementieren ist.

Das Beispiel verstehe ich auch nicht ganz, denn dazu braucht es kein sealed *shrug*.
Ein großer Vorteil von sealed interfaces in switches ist, dass es eine garantiert begrenzte Anzahl an möglichkeiten gibt. Und damit ähnlich wie enums auf "exhaustiveness" geprüft werden kann, wodruch ein ein "default" unnötig wird.