Baumstruktur in Klassen statt Array's abbilden

[kalmi01]

Hallo,

habe neulich ein Prog geladen, welches DXF lesen/schreiben kann.
Dieses Prg. läuft sehr schnell, stabil und kommt sogar spielend mit Killer-Datenmengen zurecht.

In den Sourcen wird ein TList-Objekt und eine Masterklasse abgeleitet, von denen sich
dann die nachfolgenden Klassen ableiten.

Kommt ein Knoten, wird eine neue Instanz einer Knoten-Klasse abgeleitet, welche dann wieder
neue Zeichen-Klassen beinhaltet, bis wieder ein Knoten kommt oder Ende ist.

Soetwas würde ich normalerweise mit Array's oder Records lösen, da leichter nachvollziehbar.

Jetzt zu meinen Fragen:

Die Listen der Unterklassen werden mit Listen vom Typ TList verwaltet, geht soetwas nicht auch
ohne rumge-Pointere ?

Ist so eine Klassen-Lösung einer Array-Lösung wirklich vorzuziehen ?
Der Autor hat selbst geschrieben (frei übersetzt):
Kaum zu verstehen, was wann passiert, aber es funktioniert.

Und zu guter Letzt, hat jemand ein simples Beispiel, an dem ich mich probieren kann ?
Schließlich müssen die angelegten Datenstrukturen auch wieder ausgelesen werden,
teilweise sogar selektiv.
Und spätestens beim selektiven Zugriff meine ich, wären Array's bzw. Record's besser zu handeln.

So, nun überzeugt mich mal vom Gegenteil.

[marabu]

Zitat von kalmi01:

Die Listen der Unterklassen werden mit Listen vom Typ TList verwaltet, geht soetwas nicht auch ohne rumge-Pointere?

Das ist wie beim tapezieren. Die einen nageln, die anderen kleben.

Zitat von kalmi01:

Ist so eine Klassen-Lösung einer Array-Lösung wirklich vorzuziehen?

Auf jeden Fall. Mit Vektoren bewegst Du dich noch sehr nah an der Maschine. Programmieren im Kleinen lässt sich so machen, aber wenn du mehr Funktionalität in deine Programme hineinlegen willst und dabei selbst den Überblick behalten möchtest, dann kommst du um abstrakte Datentypen und darauf aufbauende Anwendungsdatentypen nicht herum - früher oder später.

Zitat von kalmi01:

Und zu guter Letzt, hat jemand ein simples Beispiel, an dem ich mich probieren kann?

Mit einem guten Buch über abstrakte Datentypen und dem Handbuch für Object Pascal solltest Du eine Weile beschäftigt sein.

Zitat von kalmi01:

Schließlich müssen die angelegten Datenstrukturen auch wieder ausgelesen werden, teilweise sogar selektiv. Und spätestens beim selektiven Zugriff meine ich, wären Array's bzw. Record's besser zu handeln.

Das ist keine Alternative, sondern das eine baut auf dem anderen auf. Die Klasse TStack arbeitet intern mit einem Array, aber du arbeitest nur mit den Methoden Push, Pop, Peek. Der Vorteil liegt auf der Hand: Deine Klasse kann reifen, ohne dass die Programme verändert werden müssen, die diese Klasse verwenden.

Zitat von kalmi01:

So, nun überzeugt mich mal vom Gegenteil.

Ist gar nicht nötig, glaube ich. Du formulierst zwar sehr provozierend, aber zwischen den Zeilen lese ich etwas anderes.

Bleib dran, es lohnt sich.

[kalmi01]

Hallo Marabu,

danke für die Antwort.

Zitat:

Auf jeden Fall. Mit Vektoren bewegst Du dich noch sehr nah an der Maschine

Wieso bin ich mit einer Integer-Variablen als Zeiger auf Array-Position und einem "array of irgendwas" nah an der Maschine ?

Zitat:

Mit einem guten Buch über abstrakte Datentypen und dem Handbuch für Object Pascal solltest Du eine Weile beschäftigt sein.

Die Bücher, die ich bisher gesehen/gelesen habe, sind entweder so abgehoben bzw. abstrakt, daß man 3 Dekaden Informatik und Philosophie studiert haben muß, oder aber reißen das Thema nur vage an.
Oder aber, noch schlimmer, pointern selbst wie wild in der Gegend herum.

Die Klassen/Polymorphie-Beispiele Mensch/Student/Fahrrad/Auto sind mir geläufig und verständlich, aber wenig hilfreich.

Was ist denn ein gutes Buch.

Schöner wär ein Beispiel, welches nicht so überladen ist und eine reale Funktion erfüllt.

[marabu]

Zitat:

Wieso bin ich mit einer Integer-Variablen als Zeiger auf Array-Position und einem "array of irgendwas" nah an der Maschine?

Weil du so die Möglichkeit zur Abstraktion nicht nutzt, die eine Hochsprache wie Object Pascal dir bietet.

Zitat:

Die Bücher, die ich bisher gesehen/gelesen habe, sind entweder so abgehoben bzw. abstrakt, daß man 3 Dekaden Informatik und Philosophie studiert haben muß

Jedes gute Fachbuch sagt dir in der Einleitung, welcher Qualifikationsgrad vorausgesetzt wird. Du darfst diese Hinweise des Autors nicht ignorieren.

Zitat:

Was ist denn ein gutes Buch.

Das gute Buch holt dich ab, wo du stehst. Ich werde später ein paar Bücher heraussuchen, die ich mit meinen Praktikanten bearbeitet habe. Eventuell ist da etwas für dich dabei.

[kalmi01]

Hallo Marabu,

Zitat:

Jedes gute Fachbuch sagt dir in der Einleitung, welcher Qualifikationsgrad vorausgesetzt wird

das ist eine sehr praktische Erfindung, sofern man die Möglichkeit hat, diese zu lesen.
Ich hab auch schon eins gehabt, welches versprach, den geneigten (unwissenden) Leser in Delphi einzuführen.
Nach dem ersten Kapitel brauchte ich Aspirin/Cognac, Aspirin/Cognac immer im Wechsel um wieder klar zu werden.
Danach kamen nur noch WinAPI hier, Pointer dort.

Das war aus der Buchbeschreibung und der Einleitung nicht erkennbar.

OK, das war ein negativ-Beispiel, derer hab ich aber noch mehr im Schrank stehen, oft auch das genaue Gegenteil.
Lauter "Die tralala-Biebel", der "irgendwas-Profi", usw.

Die meisten landen nur nicht auf dem Scheiterhaufen, weil sie Geld gekostet haben und über einen schönen Einband verfügen.

[marabu]

Vielleicht gefällt dir dieser Versuch einer didaktischen Annäherung an das Thema.

[kalmi01]

Danke für den Hinweis,

doch ich frag mich allen Ernstes, ob man nicht auch ohne ^ und @ (in Delphi) programmieren kann ?

Delphi-Quellcode:

Zeiger     = ^Datentyp; 
Datentyp   = RECORD 
                 Inhalt        : Inhaltstyp; 
                 Nachfolger    : Zeiger; 
             END;

sind das nicht sogar Relikte aus der guten alten Turbo-Pascal-Zeit ?

Ergibt:

Delphi-Quellcode:

Zeiger = RECORD 
             Inhalt        : Inhaltstyp; 
             Nachfolger    : Zeiger; 
         END;

funktional nicht das Gleiche ?

Naja, sei's Drum, die Seite ist aber trotzdem einen Favoriten-Eintrag wert.

Kleine Anmerkung zu den Beispielen, also ich werd ja schon von einigen Kollegen als Herr_der_Leerzeichen beschimpft, aber wenn ich so einrücken würde; NaaaJaa

Übrigens (Off-Topic aber wahr):

Zitat:

Das ist wie beim tapezieren. Die einen nageln, die anderen kleben.

Wer nagelt kann Tapete und Nägel beim Umzug mitnehemen.
Geklebte Tapete löst sich bei ständig wechselnden Temperaturen/Luftfeuchtigkeiten ab,
die Genagelte wird nur wellig, bleibt aber hängen.

[bttb930]

Zitat von kalmi01:

:-D Danke für den Hinweis,

doch ich frag mich allen Ernstes, ob man nicht auch ohne ^ und @ (in Delphi) programmieren kann ?

Delphi-Quellcode:

Zeiger     = ^Datentyp; 
Datentyp   = RECORD 
                 Inhalt        : Inhaltstyp; 
                 Nachfolger    : Zeiger; 
             END;

sind das nicht sogar Relikte aus der guten alten Turbo-Pascal-Zeit ?

Ergibt:

Delphi-Quellcode:

Zeiger = RECORD 
             Inhalt        : Inhaltstyp; 
             Nachfolger    : Zeiger; 
         END;

funktional nicht das Gleiche ?

NEIN, das ist nicht dasselbe!!!

Ich denke mal dass das zweite Beispiel sich nicht mal compilieren lässt.

Das Problem ist RECORD - sobald Du Klassen benutzt bist Du nah dran, aber mit RECORDs definitiv nicht.

[bttb930]

Zitat von marabu:

Vielleicht gefällt dir dieser Versuch einer didaktischen Annäherung an das Thema.

Moment mal, erst sagst Du man solle die Abstraktion nutzen, die eine höhere Programmiersprache wie Delphi mir bietet, und dann verweist Du auf eine Seite auf der direkt mit Zeigern programmiert wird?

Lies dir mal die Quellcodes durch - die stehen im Widerspruch zu deinen beiträgen in diesem Thread.

Man sollte Klassen verwenden, keine Arrays und keine Records. Und da braucht man kein ^ und kein @.

[Robert_G]

Zitat von bttb930:

Man sollte Klassen verwenden, keine Arrays und keine Records. Und da braucht man kein ^ und kein @.

Amen
Einen PSomeBloodyRecord zu benutzen nur um sich vor Assigment By Copy zu drücken muss wohl irgendwie cooler zu sein, als ästhetischer OO Code.