N
redoundo schrieb:
Und was würdest du für alternativen vorschlagen? (Für Vererbung, nicht für goto)
Strukturen oder Klassen ohne Vererbung benutzen und die Vererbung in die Programmlokik einbauen.
Beispiel von mir:
Ich mache eine Semantikanalyse für C-Quelltext. Dazu ist es erforderlich eine Symboltabelle mit Symboltabelleneinträge zu haben. Darin stehen Dinge wie Name, Art, Zeile und so weiter. Verschiedene Variablentypen brauchen nun verschiedene Extras. Primitive Datentypen brauchen den Datentyp, Prototypen brauchen den Rückgabewert und eine Symboltabelle mit Parametern, Funktionen brauchen dasselbe wie Prototypen + eine Symboltabelle für lokale Variablen.
Meine Struktur (eigentlich ist es eine Klasse) sieht nun gekürzt so aus:
struct Symboltabelleneintrag{
char *name;
unsigned int line;
int type;
union typeformat;
};
union typeformat{
struct funktionstyp *funktion; //wird auch für Prototypen verwendet
char *primitivetyp;
struct strukturtyp *struktur;
};
Ich hoffe mal du siehst die "Vererbung" in der Struktur.
Die Alternative wäre eine abstrakte Symboltabelleneintrag-Klasse zu bauen und dann Primitivtyp, Structtyp und Prototyptyp davon abzuleiten und Funktionstyp von Prototyp abzuleiten.
Im Prinzip tut beides dasselbe.
Ich vergesse allerdings ständig welche Member die Objekte haben. Bei Structs kann ich einfach nachsehen. Bei Klassen nicht. Wenn ich einen struct Symboltabelleneintrag* gegeben habe habe ich alle Informationen über den Eintrag. Wenn ich einen class functiontyp* habe muss ich mir die einzelnen Daten mühsam aus den Klassen zusammensammeln.
Da ich nicht sonderlich viel RAM im Hirn habe, habe ich nach dem Zusammensammeln der einzelnen Elemente aus den Klassen vergessen was ich eigentlich machen wollte.
Beispiel von Microsoft:
Man benutzt die WinAPI um Fenster zu machen. Fenster haben ein paar Eigenschaften wie Titel und den dazugehörigen Message Handler. Man könnte eine allgemeine Fensterklasse bauen und Tooltips, Tabs, Textfenster und so weiter davon ableiten.
Stattdessen gibt es für die WinAPI Subclassing. Man nimmt zum Beispiel ein Textfeld, findet es ganz nett, will aber zusätzlich auf Rechtsklicks reagieren und ein Menü anzeigen. Also macht man sich ein Standard-Textfeld wo das Tippen, malen der Buchstaben und so weiter vom Defaultmessagehandler übernommen wird und tauscht einfach nur den Messagehandler mit SetWindowLong aus. Dieser neue Messagehandler reagiert nun auf Rechtsklicks und den Rest lässt er den Defaultmessagehandler machen.
Ich denke mal hier ist klar Vererbung erkennbar. Außerdem ist genau nachvollziehbar was wo passiert.
Wenn man stattdessen Klassen benutzt (MFC macht das glaube ich), dann sieht man nicht mehr durch, denn um herauszufinden welches Objekt für den Fensterstil zuständig ist muss man viiiiiel Code wälzen. Bei der WinAPI sieht man sich die Doku für SetWindowLong und fertig, da stehen alle Möglichkeiten aufgelistet.
Sieht man sich hingegen die Dokumentation der Textfensterklasse an steht dort nirgends was vom Messagehandler, sondern nur textfensterspezifische Optionen. Und dann geht die Suche los, die Klasse erbt von sonstwievielen anderen Klassen die man alle durchsuchen darf.
Einen Teil der Unübersichtlichkeit lässt sich durch semantische IDE's und redundante Dokumentationen umgehen. Das ist aber nicht viel besser als ein Texteditor der bunt anzeigt welches goto zu welchem Label springt. Es hilft, löst aber das Problem nicht.
Bei Wiki gibts eine nette Liste über Kritik an objektorientierten Sprachen.
Objektorientiertes Programmieren und Vererbung kann hilfreich sein und man kann es benutzen, auch in C, aber Objektorientierung wo keine Objekte sind und Mehrfachvererbung nur um des Vererbens Willen (siehe erster Post) schadet nur.
