Forward in Klassen funktioniert nicht

[Dejan Vu]

Zitat von BadenPower:

Aber um dann miteinander arbeiten zu können, müssen beide einen 3. kennen. ...Warum also einen dritten hinzuziehen, wenn die beiden Klassen zusammengehörig sind und gegenseitig miteinander über den direkten Weg agieren können.

Wegen der Wiederverwendbarkeit, z.B. Zirkuläre Referenzen sind eigentlich nie sinnvoll. Es verbindet beide Klassen unauslöschlich miteinander. Meistens (eigentlich immer) ist es ein Designfehler. Mir fällt kein sinnvolles Beispiel ein, wo zwei *Klassen* sich kennen müssen. A verwendet B, aber B muss A konkret nicht kennen, höchstens ein von A implementiertes Interface. Und -wupps- haben wir die zirkuläre Referenz aufgelöst.

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt. Oder teilweise Kopfschütteln.

Zitat:

Ich bin für Vorwärts-Deklarationen auch bei Klassen.

Wie fein. Andere Leute finden Bollerwagen toll. Aber das Transportgewerbe setzt gemeinhin auf bessere Lösungen.

[DeddyH]

[BadenPower]

Zitat von Dejan Vu:

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt.

Mich wundert es nicht, wenn ich für meine Meinung Gegenargumente bekomme, aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Eine Funktion ist immer dazu da, benutzt zu werden.

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen, oder seine komplett selbst programmierte VCL zu benutzen.
Sollte man allerdings tun, wenn man auf die "Grundregeln moderner Softwarearchitektur" besteht.

[Dejan Vu]

Zitat von BadenPower:

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch?

Zitat:

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen,

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon. Ein TTabSheet möchte vielleicht einmal in einem anderen Container sein, als in einem TPageControl. Das geht so aber nicht. Wäre das TTabsheet nur abhängig von einem Container, der die notwendigen Methoden des TPageControl implementiert, ginge das.

Zitat:

aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Och, auch mit Delphi kann man recht sauberen Code produzieren. Man muss einfach nur die Anti-Pattern vermeiden.

Im Übrigen gilt in der modernen Softwarearchitektur auch und besonders, das man bestehende Frameworks benutzen sollte, wenn dies (TOC) günstiger ist, als selbst etwas zu entwickeln. Also verwende ich zähneknirschend die VCL und auch mal so ein in seiner Freiheit eingeschränktes TTabSheet.

[BadenPower]

Zitat von Dejan Vu:

Och, auch mit Delphi kann man recht sauberen Code produzieren.

Du widersprichst Dir selbst.

Einerseits sagst Du, dass Forward-Deklarationen von Klassen nicht den "Grundregeln moderner Softwarearchitektur" entsprechen, andererseits verwendest Du Delphi, welches voll ist mit Klassen-Forward-Deklarationen.

Entweder sind dann auch Klassen-Forward-Deklarationen "sauberer Code" oder Dein Programm hat KEINEN sauberen Code, denn Dein Programm besteht zu einem sehr großen Teil aus Delhi-Code.

Du solltest Dich für eine Variante entscheiden.

Zitat von Dejan Vu:

Zitat:

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen,

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon.

Also ich habe ein eigenes TPageControl und ein eigenes TTabSheet und habe es dennoch nicht übers Herz gebracht eine unnötige 3. Klasse zu erstellen, damit sich beide Klassen unterhalten können oder gar in zwei verschiedenen Units ihr Dasein zu fristen.

Zitat von Dejan Vu:

Zitat von BadenPower:

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch?

Selbstverständlich.

Auch ein "Goto" war ein sehr gut einzusetzender und effektiver Befehl.

[ATS3788]

Sir Rufo

Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh
Nur warum ging das mit der Lokalen Variablen
dann wäre mir das auch aufgefallen.
Ein schönes Weihnachtsfest.

Zitat:

http://www.delphipraxis.net/183177-d...scheidung.html
Schaut doch mal in den Beitrag von mir. Knapp 700€ für XE7 sind viel Geld
wenn man kein Geld mit Programmieren verdient. Vielleicht habt ihr ja noch
eine gute Idee.

[BadenPower]

Zitat von ATS3788:

Sir Rufo
Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh

Die Antwort hat Dir bcvs bereits auf der 1. Seite im 3. Post gegeben und im Post 16 auf Seite 2 nochmals darauf hingewiesen.

[bcvs]

Zitat von BadenPower:

Zitat von ATS3788:

Sir Rufo
Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh

Die Antwort hat Dir bcvs bereits auf der 1. Seite im 3. Post gegeben und im Post 16 auf Seite 2 nochmals darauf hingewiesen.

Und ich habe schon gedacht, meine Posts würden irgendwie verschluckt und außer mir sieht sie niemand.

[himitsu]

Der Stack existiert immer, egal ob es das Objekt gibt oder nicht,
drum funktionieren lokale Variablen immer.

Globale Variablen liegen auf dem Heap und der ist auch immer da.

Felder (Veriablen in der Klasse) liegen immer in der Klassen-Instanz und ist die weg, dann sind die auch weg.

Die Variable (mit der Klasseninstanz) wird als Self in die Methode reingegeben und solange man nicht auf Self (also auf irgendwas in der Instanz) zugreift, kann auch nichts passieren.
Die Methode wird dann quasi zur Klassen-Methode (class function).