Strukturierungsproblem (Units, Klassen)

[Cöster]

Hi!

Mein bisheriger Programmaufbau (bestehend aus 3 Units) sieht skizziert so aus:

Delphi-Quellcode:

unit Unit1;

uses
  {...} Unit2, Unit3;

interface

type
  TForm1 = class(TForm)
  {...}

Delphi-Quellcode:

unit Unit2;

interface

type
  TKlasse1 = class
  private
    {...}
  end;
  
  TKlasse2 = class
  private
    Field: array of TKlasse1;
  public
    {...}
  end;
{...}

Delphi-Quellcode:

unit Unit3;

interface

type
  TKlasse3 = class
  private
    {...}
  public
    {...}
  end;
{...}

TForm1 kann also auf einige Methoden von TKlasse2 und TKlasse3 zugreifen. Nun soll TKlasse3 aber auf die Eigenschaften zugreifen, die im private-Teil von TKlasse1 stehen, TForm1 darf das nicht. Sollte ich TKlasse3 dazu auch in Unit2 zu stecken? Oder gibt es eine Möglichkeit, bei der TKlasse3 weiterhin in einer eigenen Unit stehen kann? Was müsste ich dazu umbauen?

[thkerkmann]

Hi,

also du hast dir ja was dabei gedacht, die Klasse3 in eine eigene Unit zu stecken, oder ?

Wenn also jetzt diese Klasse auf private Elemente der anderen Klasse zugreifen soll, dann sind die entweder nicht wirklich so privat, oder Klasse3 steht doch in einem engeren Zusammenhang zu Klasse1 und Klasse2. Dann wäre es natürlich sinnvoll diese in der selben unit zu haben.

Denk nochmal über die Zusammenhänge der drei Klassen untereinander nach, dann kommst du auf die für dich richtige Lösung.

Gruss

Thomas.

[Muetze1]

Du hast ja mehrere Möglichkeiten in einer Klasse Sichtbarkeiten festzulegen. Dir steht dafür private, protected, public und published zur Verfügung. Wenn du nun in einer Klasse Dinge im private Abschnitt der Klasse deklarierst, dann definierst du, dass nur noch diese Klasse und keine abgeleitete Klasse und auch keiner von außen auf diese Daten zugreifen darf/soll. Bei dir mit Klasse1 und Klasse2 nutzt du dafür das Verhalten von Delphi aus, dass Klassen in einer Unit alle zueinander verhalten wie friend Klassen. Das heisst, jede Klasse in der Unit darf auch auf die private und protected Elemente der anderen Klassen von außen zugreifen.

So, das mal zur Theorie. Nun stellt sich bei deinem Problem die Frage: Warum hast du die Dinge im private Abschnitt definiert, wenn du sie doch von außen zugreifbar benötigst? Du könntest nun entweder die Daten in den Public Bereich verschieben oder mit Properties arbeiten, welche dir die Möglichkeit bieten die Private Elemente nach außen sichtbar zu machen und gleichzeitig dir alle Möglichkeiten zur Kontrolle der Zugriffe zu geben.

Die Frage ist nun: wodran liegt es? Falsches Design der Klassen oder fehlendes Wissen? Um zu einer Lösung zu kommen müssten wir wissen, was du erreichen willst. Warum sind die Daten private, müssen sie private sein, wenn ja, warum musst du dann mit Klasse3 drauf zugreifen?

[Cöster]

Zitat:

Zitat von thkerkmann

also du hast dir ja was dabei gedacht, die Klasse3 in eine eigene Unit zu stecken, oder ?

Ja, ich dachte mir einfach nur: Neue Klasse, dann nehm ich auch ne neue Unit :mrgreen: Ist vielleicht die falsche Denkweise. Klasse1 und 2 hab ich in eine Unit gesteckt, weil Klasse2 als einzige Eigenschaft einen array of Klasse1 hat.

Zitat:

Zitat von Muetze1

Warum hast du die Dinge im private Abschnitt definiert, wenn du sie doch von außen zugreifbar benötigst? Du könntest nun entweder die Daten in den Public Bereich verschieben oder mit Properties arbeiten, welche dir die Möglichkeit bieten die Private Elemente nach außen sichtbar zu machen und gleichzeitig dir alle Möglichkeiten zur Kontrolle der Zugriffe zu geben.

Aber wenn ich sie public deklariere, wären sie ja auch für Form1 sichtbar. Das sollen sie eigentlich nicht.

Zitat:

Zitat von Muetze1

Warum sind die Daten private, müssen sie private sein, wenn ja, warum musst du dann mit Klasse3 drauf zugreifen?

Das ganze soll ein Spiel werden. Klasse1 ist ein Spielball. Klasse2 sind alle Spielbälle (array of Klasse1). Aus Form1 wird nie direkt auf Klasse1 zugegriffen, sondern immer nur auf Klasse2, da die Aktionen immer mit allen Bällen gleich durchgeführt werden. Klasse1 hat deswegen nur Private-Elemente.
Klasse3 ist die Umgebung. In ihr wird gespeichert, wo z.B. Wände sind, gegen die die Spielbälle nicht prallen dürfen. In Klasse3 stehen die Kollisionsüberprüfungsmethoden. Um nach einer Kollision zu prüfen, muss Klasse3 die Koordinaten der Spielbälle kennen. Form1 braucht diese allerdings nicht zu kennen, deswegen sind sie im Private-Abschnitt deklariert.

[Muetze1]

Ok, folgendes:

1. Klasse 1 bekommt alles für die Bälle wichtige. Ein Ball sollte alles wichtige (ver)öffentlich(en) was ihn beschreibt. Grösse, Geschwindigkeit, Farbe, Position, etc.

2. Klasse 2 sollte eine Ableitung von einer Liste sein. Ich würde dort TObjectList oder sonst auch TList nehmen.

3. Klasse 3 bekommt alles für's Spielfeld wichtige. Klasse 3 legt intern eine Instanz von Klasse 2 an und hat damit sofort und immer Zugriff auf die Position aller Bälle, da er auf die Ballliste zugreifen kann und damit auf die Eigenschaften der eigentlichen Bälle.

[Cöster]

Zitat:

Zitat von Muetze1

2. Klasse 2 sollte eine Ableitung von einer Liste sein. Ich würde dort TObjectList oder sonst auch TList nehmen.

Die Idee find ich gut. Ich probier's mit TObjectList mal aus.

Zitat:

Zitat von Muetze1

3. Klasse 3 bekommt alles für's Spielfeld wichtige. Klasse 3 legt intern eine Instanz von Klasse 2 an und hat damit sofort und immer Zugriff auf die Position aller Bälle, da er auf die Ballliste zugreifen kann und damit auf die Eigenschaften der eigentlichen Bälle.

Also läuft das ganze Spiel über Klasse3? Dann könnte ich auch alle privaten Methoden aus Form1 rausnehmen und in Klasse3 verlagern. Wär vielleicht auch besser, weil ich dadurch strenger GUI von Logik trenne. Dann gibt es in Form1 gar keine privaten Elemente mehr.

Ich versuch das alles mal umzusetzen. Vielen Dank an dich! :dp:

Eine Frage hab ich allerdings noch:

Zitat:

Zitat von Muetze1

Ein Ball sollte alles wichtige (ver)öffentlich(en) was ihn beschreibt.

Warum? Dann sind die Eigenschaften doch auch für Form1 sichtbar. Ist sowas in solchen Fällen egal?

[Muetze1]

Zitat:

Zitat von Cöster

Zitat:

Zitat von Muetze1

Ein Ball sollte alles wichtige (ver)öffentlich(en) was ihn beschreibt.

Warum? Dann sind die Eigenschaften doch auch für Form1 sichtbar. Ist sowas in solchen Fällen egal?

Weil sonst deine Klasse2 und Klasse3 nicht an die benötigten Informationen rankommen. Und wie sollte denn die Form auf die Klasse1 zugreifen? Unit2 (Klasse1 und Klasse2) braucht Form1 nicht einzubinden und Klasse3 in Unit3 bindet die Liste der Bälle private ein. Daher wüsste ich nicht, wie das gehen sollte?

[Cöster]

Zitat:

Zitat von Muetze1

Weil sonst deine Klasse2 und Klasse3 nicht an die benötigten Informationen rankommen. Und wie sollte denn die Form auf die Klasse1 zugreifen? Unit2 (Klasse1 und Klasse2) braucht Form1 nicht einzubinden und Klasse3 in Unit3 bindet die Liste der Bälle private ein. Daher wüsste ich nicht, wie das gehen sollte?

Stimmt, dann kann Form1 doch nicht drauf zugreifen, weil es Klasse1 ja gar nicht kennt. Das ginge ohne publics wohl sonst nur, wenn man Klasse3 auch noch in Unit2 steckt. Was wäre da denn eleganter und was performanter?

[Muetze1]

Zitat:

Zitat von Cöster

Stimmt, dann kann Form1 doch nicht drauf zugreifen, weil es Klasse1 ja gar nicht kennt. Das ginge ohne publics wohl sonst nur, wenn man Klasse3 auch noch in Unit2 steckt.

Richtig, weil du dann wieder das Friend Class Prinzip ausnutzen würdest.

Zitat:

Zitat von Cöster

Was wäre da denn eleganter und was performanter?

Ich persönlich das exzessive ausnutzen des Friend Class Prinzips nicht gut. Schon allein die Ableitfähigkeit der Klassen sinkt damit rapide. Auch sehe ich in diesem Fall wirklich keinen Grund hier so strikt zu trennen. Man könnte sogar alle Klassen in eine eigene Unit auslagern was deren Übersichtlichkeit innerhalb des Projektes fördert und auch des Quellcodes.

[Cöster]

Zitat:

Zitat von Muetze1

Man könnte sogar alle Klassen in eine eigene Unit auslagern was deren Übersichtlichkeit innerhalb des Projektes fördert und auch des Quellcodes.

Das meinte ich doch, Klasse1 bis 3 in eine Unit. Oder beziehst du hier TForm1 auch noch mit ein?

Nur was mich daran stört, wenn das ganze Spiel über Klasse3 läuft: In Form1 wird in der Timer-procedure die Neu-Berechnen-Prozedur aus Klasse3 aufgerufen. Diese ruft die Kollisionsüberprüfung aus Klasse3 (aus der u.a. die voneinander-Abprall-Prozedur aus Klasse2 aufgerufen wird) und die Neu-Berechnen-Methoden aus Klasse2 auf. Von dort aus wird dann für jeden Ball die Neu-Berechnen-Methode aus Klasse1 aufgerufen. Kostet das nicht unnötig viel Zeit oder optimiert der Compiler das automatisch?
Wenn Klasse1, 2 und 3 alle in einer Unit stünden, würde ich mir hierbei den Umweg über Klasse3 sparen. Andererseits wäre die Trennung zwischen GUI und Berechnungen dann nicht ganz so ausgeprägt vorhanden.

EDIT: ich glaub, ich hab das, was ich zitiert hab, genau falsch verstanden