500 Zeilen interface-Teil. Ist das normal?

[MarcusB]

Hi,

hier mal wieder der interessierte Delphi-Laie.

Ich arbeite gerade an meinem bislang größtem Programm und habe bereits jetzt über 500 Zeilen allein für den Interface-Teil.
Ich habe so an die 20 Checkboxen, 80 Editfelder und etwa 15 Combos.
Dazu noch einen Haufen type-Deklarationen.

Das ganze wird langs unheimlich unübersichtlich. Ist das eigentlich normal bei einer Anwendung mit sovielen Felder, bzw. gibt es da gewisse Kniffe um das etwas übersichtlicher zu gestalten?

Ich blick nämlich bald nicht mehr durch

Da die IDE ja leider kein Code-Folding beherrscht ist es schon recht mühsam.
Ich habe ja schon dran gedacht einiges in eine andere Unit auszulagern, aber ich brauche ja immer immer den Bezug zu meinen ganzen Edits und Combos etc.

Wie machen denn die Profis unter Euch sowas?

[GuenterS]

Du solltest mehrere Units verwenden und vor allem GUI weitestgehend von ProgrammLogik trennen.

Zum Beispiel kannst Du
Typdeklarationen wie records, Aufzählungstypen, Constanten in eine eigene Unit auslagern.

[MarcusB]

Ich bin ja da nicht so ganz firm.

[edit:] Ok, das hab ich grad kapiert

Zitat:

Zum Beispiel kannst Du
Typdeklarationen wie records, Aufzählungstypen, Constanten in eine eigene Unit auslagern.

Auch die, die ich innerhalb meiner Form1 verwende?
[/edit]

Und das Trennen von Programm und GUI ist für mich auch etwas schwierig,
da ich fast in jeder Funktion auf irgendein Edit-Feld oder Combo zugreife.

Oder mach ich da grundsätzlich was falsch?

[GuenterS]

Wenn Du die die Unit in welche Du deine Records ausgelagert hast, in der anderen einbindest geht das.


Kleines Beispiel:

Delphi-Quellcode:

unit uMySecondUnit;

interface

type
   PMyRecord = ^TMyRecord;
   TMyRecord = record
      Field1, Field2, Field3: string;
   end;

   TDialogButtons = (tbOK, tbCANCEL, tbYESNO);

const
   CLanguage_de = 'Deutsch';
   CLanguage_en = 'Englisch';

implementation

end.

Delphi-Quellcode:

unit uMyFirstUnit;

interface

uses
   uMySecondUnit;

type
  
   TMyObject = class(TObject)
   private
      FMyRecord: TMyRecord;

      FLanguage: string;
   public

      procedure SetDlgButtons(AButton: TDialogButtons);

      property MyRecord: TMyRecord read FMyRecord write FMyRecord;
   end;

implementation

procedure TMyObject.SetDlgButtons(AButton: TDialogButtons);
begin
  if (AButton = tbOK) then
     FLanguage := CLanguage_de
  else 
     FLanguage := CLanguage_en;
end;

end.

[MarcusB]

Uff, ich sehe schon, ich muss mich mit der Problematik jetzt mal ganz intensiv beschäftigen.
Danke schon mal für deinen Hinweis.

Da ich bisher immer nur so kleinere Sachen gemacht habe, habe ich mich da nicht näher drum gekümmert.
Wo bekommt man denn dazu gute Infos?

Meine Delphibücher geben da leider wenig her (oder jedenfalls nicht verständlich genug für mich).

[Phoenix]

Also ich bin gerade an einem kleinen Projekt mit knapp 1077 Zeilen interface, die Implementationen habe ich dann in verschiedene Dateien (pro Klasse eine eigene) ausgelagert.

Problematisch ist, das sich die Klassen gegenseitig brauchen und ich sie von daher gar nicht Sinnvoll in verschiedene Units aufteilen könnte. Natürlich wird das u.U. etwas unübersichtlich, aber man arbeitet im Regelfall eh nur an einer Klasse gleichzeitig (sprünge sind zumindest bei mir relativ selten) und von daher reicht es in der Unit dann einfach zu der jeweiligen Deklaration zu scrollen und dann die entsprechende implementation-Datei parallel dazu auf zu haben.

[GuenterS]

Zitat von Phoenix:

Also ich bin gerade an einem kleinen Projekt mit knapp 1077 Zeilen interface, die Implementationen habe ich dann in verschiedene Dateien (pro Klasse eine eigene) ausgelagert.

Problematisch ist, das sich die Klassen gegenseitig brauchen und ich sie von daher gar nicht Sinnvoll in verschiedene Units aufteilen könnte. Natürlich wird das u.U. etwas unübersichtlich, aber man arbeitet im Regelfall eh nur an einer Klasse gleichzeitig (sprünge sind zumindest bei mir relativ selten) und von daher reicht es in der Unit dann einfach zu der jeweiligen Deklaration zu scrollen und dann die entsprechende implementation-Datei parallel dazu auf zu haben.

Wieso müssen mehrere Klassen in eine Unit?

In der arbeit haben wir die Regel für jede Klasse eine eigene Unit und das funktioniert, ganz ohne Probleme.

Wenn Du dann eine Klasse aus einer anderen Unit brauchst, mußt Du diese eigentlich nur "usen".

[Phoenix]

Das geht genau dann nicht, wenn sich die Klassen gegenseitig brauchen.

Beispiel: Liste enthält mehrere andere Listen. Jede dieser Listen muss hingegen ein eigenes Property auf das des Owners mappen. Somit müssten sich beide Units im Interface-Teil gegenseitig referenzieren, aber Kreuzbezüge sind nicht erlaubt. Daher müssen die in eine Unit.

Nachtrag: An der Stelle lässt sich das leider gar nicht nicht vermeiden, da das ganze ein Wrapper ist und die zugrundeliegenden Klassen schon dieses Design mitbringen.

Zudem wird das hinterher für die Zielentwickler einfacher, da diese zum Verwenden der KLassen nur noch eine Unit einbinden müssen und nicht für jede Klasse eine einzelne.

[GuenterS]

Naja ok, eine Unit haben wir auch mit fast 9000 Zeilen.

[mytar]

Wichtige OOP-Regel:
GUI-Schicht und Fachkonzeptschicht trennen!

greetz
mytar