Programmierstil - Bei Vererbung welchen Typ benutzen?

[dwn8]

Hallo,

meine Frage ist: Welchen Typ verwendet man normalerweise, wenn man Objekte von Unterklassen zuweist?
Z.B. erzeuge ich ein eigenes JFrame (MyJFrame) oder ein eigenes TreeModel (MyTreeModel).
Welchem Typ weist man diese Objekte zu, JFrame oder MyJFrame; oder bei dem zweiten Beispiel: TreeModel oder
MyTreeModel.

Ich würde jeweils den "größeren" Typ nehmen, da man dann einfach auch andere Unterklassen dieses Typs benutzen kann.

Gruß
dwn8

 

[The_S]

Versteh ich nicht. Wenn du ein MyJFrame benötigst, dann machst du

MyJFrame frame = new MyJFrame();

wenn du aber ein JFrame benötigst, dann machst du

JFrame frame = new JFrame();

selbes gilt natürlich auch für dein TreeModel ???:L

 

[tfa]

Ich glaube er meint sowas:

JFrame meinFrame = new MyFrame();
TreeModel meinModel = new MyTreeModel();

Ich würde in der veröffentlichen Schnittstelle (also public oder protected Member) immer den
allgemeinen Typ angeben. In privaten Methoden oder lokalen Variablen ist der Subtyp auch ok.

 

[matches]

Wenn du es so machst, wie tfa es beschrieben hat, hast du aber folgendes Problem.

Implementierst du in deiner eigenen Klasse MyFrame zusätzliche Methoden, musst du beim Zugriff auf diese immer zuerst einen Cast machen.

 

[HLX]

Wenn du es so machst, wie tfa es beschrieben hat, kannst du in der öffentlichen Schnittstellen mehrere Subtypen des allgemeinen Typs verarbeiten. Außerdem kannst den Subtyp durch einen beliebigen anderen Subtyp austauschen ohne die Schnittstelle ändern zu müssen.

 

[Guest]

Wenn du es so machst, wie tfa es beschrieben hat, kannst du in der öffentlichen Schnittstellen mehrere Subtypen des allgemeinen Typs verarbeiten. Außerdem kannst den Subtyp durch einen beliebigen anderen Subtyp austauschen ohne die Schnittstelle ändern zu müssen.

Ja man könnte dann über die Schnittstellen mehrere Typen verarbeiten, aber solang mehrere Typen nicht vorliegen lohnt es sich nicht. Außerdem sollte die Initialisierung bei diesem vorgehen dann nicht in dieser Klasse erfolgen. Dafür müsste dann ein Builder oder eine Factory verwendet werden. Mehr dynamik bring einem auch nur etwas wenn man sie benutzt, ansonsten ist es besser dem KISS Prinzip zu folgen.

 

[Gast]

Ich schließe mich TFA an und verdeutliche seine Aussage nochmal:

bei public/protected methoden, sowie bei interfaces die Parameter
-> so allgemein wie möglich, so genau wie nötig.

damit erhöhst du die wahrscheinlichkeit der wiederverwendung!

in private methoden trifft dies nur bedingt zu, denn diese können weder vererbt noch von außerhalb aufgerufen werden, also habe ich hier keinen vorteil eine möglichst allgemeine funktion zu schreiben.. im gegenteil: private methoden sind sehr konkret

 

[Marco13]

Ich würde in der veröffentlichen Schnittstelle (also public oder protected Member) immer den allgemeinen Typ angeben.
Im Prinzip stimme ich da zu, aber ... "den allgemeinen" Typ gibt es eben nicht, bzw. "der allgemein(st)e" Typ ist immer ....
Object someMagicObject = new MeinTableModel(); :wink:

Als Faustregel würde ich vielleicht sowas sagen wie "So allgemein wie möglich, aber so konkret wie unbedingt nötig" (oder so :? )

Das "unbedingt" ist dabei ziemlich wichtig - in gewisser Hinsicht besteht ein kleiner Teil der Kunst der Programmierung IMHO darin, diese Bedingungen möglichst "schwach" zu halten. Im Idealfall sollte z.B. das TableModel IMMER NUR als TableModel verwendet werden, und NIE als MeinTableModel. Praktisch sollten die Stellen, an denen wirklich MeinTableModel benötigt wird, damit minimal gehalten werden (oder versteckt, mit der schon angesprochenen Factoy).

 

[Guest]

Ich habe es so wie tfa geschrieben hat gemeint.
Danke für die Antworten!