Vererbung von Dialogen

[Thomas Schlebach]

Hallo NG

Angenommen ich habe eine Anwendung (Applikation) mit einem Menue und einer bestimmten Anzahl von Dialogen die ueber Menuepunkte aufgerufen werden. Einige der Dialoge sind in ihrer Grundstruktur immer gleich (also z.B. immer 4 Buttons unten ... eine Tabelle in der Mitte usw.). Macht es Sinn eine sogen. Superklasse mit der Grundstruktur zu erzeugen und alle anderen Dialoge von dieser abzuleiten und dann event. zusätzliche Controlls (Buttons...) einzubauen? Oder kann das Vererben zu Problemen fuehren?

mfG

Thomas

[Juergen Wolther]

Hi Thomas,

ganz klare Antwort: Vererbung schadet nicht der Gesundheit ;-)
Im Ernst: Genau das ist Sinn und Zweck der Objektorientierten Programmierung, nämlich Klassifizierung, d.h. Datenobjekte, die Atrribute und / oder Methoden gemein haben in eine Klasse zusammenzufassen und somit leichter mit den, meist hunderten, Datenkonstrukten in einem Softwareprojekt umgehen zu können.

Also, wann immer Du im Laufe Deiner Entwicklungsarbeit feststellst, dass Dinge im grossen und ganzen vieles gemeinsam haben, tu das, was Du auch als biologischer Mensch tust: klassifiziere. Der Objektorientierte Ansatz ist gerade deshalb so effizient, weil er, wenn richtig verstanden und angewandt, dem täglichen, intuitiven Denken, Planen und Verhalten des Menschen zumindest sehr ähnlich ist.
Das Ableiten einer Klasse von einer anderen kann meinen Infos nach niemals schädlich sein.

Ich würde Dir folgendes Empfehlen: Denke generell bei jedem 'grösseren' Datenkonstrukt (z.B. Panels mit Controlls drin oder auch komplette Dialoge) nach, ob Du nicht eine eigene Klasse davon ableiten möchtest. Natürlich kann man JPanel und Konsorten auch nutzen ohne eine eigene Klasse davon abzuleiten. Ich habe mir aber mit der Zeit angewöhnt von nahezu jedem Datenobjekt, dass ich verwende eine eigene Klasse abzuleiten. Das vermeidet oft Verwechselungen und andere Irrtümer, weil ich genau weiss, dass ich es mit einer konkreten Instanz einer von mir entwickelten und zum jeweiligen Projekt gehörigen Klasse zu tun habe. Es erleichtert zudem die Vorgehensweise, wenn Du im Entwicklungsprozess feststellst, dass sich eine Deiner Klassen als Basisklasse für andere Klassen eignet.

Und nun noch ein interessanter Tip: Wenn Du feststellst, dass Du in mehreren Projekten im Laufe der Zeit ähnliche Datenkonstrukte nutzt, dann lagere diese in ein eigenes Projekt aus, dass Du zum Beispiel TFC (ThomasFoundationClasses) nennst. Dort kannst Du Dir dann Deine eigene Klassenbibliothek aufbauen. Solch eine eigene Klassenbibliothek bezeichne ich als die Schatzkiste eines jeden Entwicklers, denn die Schätze, die sich dort mit der Zeit ansammeln sind Gold wert, weil sie den Entwicklungsprozess jeder neuen Anwendung meist signifikant verkürzen.

Ein Beispiel zum Schluss: Eines Tages stellte ich beim Entwickeln einer Anwendung fest, dass ich es gern mag, wenn Applikationsfenster, Dialoge etc. zentriert auf dem Bildschirm erscheinen. Ich schrieb also für die betreffende Anwendung eine Klasse CenteredFrame und CenteredDialog. Bei Entwicklung der nächsten Anwendung stellte ich fest, dass ich wieder zentrierte Fenster und Dialoge benötigte. Also verschob ich die Sourcen für den Dialog und den Frame in das Projekt meiner Klassenbibliothek und leite heute alle Frames und Dialoge (soweit Zentrierung erwünscht) von den Centered-Varianten ab.

So hat sich im Laufe der Zeit eine Klassenbibliothek von sage und schreibe 486 Klassen für die verschiedensten Zwecke angesammelt, die mir viel Arbeit spart.

So, das war lang ;-) Ich hoffe ich konnte Dir etwas helfen.

Gruss

Jürge