Dateien umbennen - welches Namensformat?

Hierzu eine abschließende Frage:

Utils.Logging.pas:
- enthält Funktionen und Prozeduren betreffend "Logging"
- Funktionen und Prozeduren von Utils.Logging können von anderen Units verwendet werden, indem man die Utils.Logging-Unit in weitere Units einbindet

Types.Logging.pas:
- enthält Record-s, Class-es, Enums etc, welche nur in Utils.Logging verwendet werden
- wird in Utils.Logging.pas eingebunden, sonst nirgendwo

Ist das richtig so von der Logik oder stelle ich mir gerade ein Bein und habe irgendetwas noch nicht verstanden?

Sinn soll es ja u.a. sein, dass man so wenig Abhängigkeiten zu anderen Units wie möglich hat nehme ich an?
Falls dem so ist, darf man denn dann überhaupt in Utils.Logging.pas weitere Units einbinden?
Angenommen ich habe eine Unit mit Variablen die programmweit verfügbar sein sollen und eine davon benötige ich in Utils.Loggins.pas.
Wie sähe das konkret aus?

Hier ist das, was ich bisher verstanden habe

zusammenfalten · markieren

Delphi-Quellcode:

			unit Types.Logging;

interface

uses

 System.Classes, System.SysUtils, ...;

type

 TBeispielEnum = (test, blub);

implementation

end.

/////////////////////////////////////////////////

unit Utils.Logging;

interface

uses

 Types.Logging, // darf Types.Logging verwenden für eventuelle spätere Zugriffe auf TBeispielEnum (?)

 System.Classes, System.SysUtils, ...;

type

 TLogging= class

 private

  //

 public

  class function Test(iiiii: Integer): Integer; static;

 end;

implementation

// uses .... ; // <= andere Units des Programms einbinden, ist das erlaubt?

class function TLogging.Test(iiiii: Integer): Integer;

begin

 Result := iiiii + 1;

end;

end.

////////////////////////////////////////

showmessage( IntToStr( TLogging.Test(1) ) );

P.S.: der Code würde -50 von 100 Punkten erhalten, wenn es um den Sinn und die Funktionalität ginge.

**himitsu**

Ich würde es ja andersrum machen.

Logging.Utils.pas
Logging.Types.pas

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen
und bei Codevervollständigung und Unitsuche nach "Log", "Logging." usw. sieht man alles, was zum Logging gehört oder was sonst noch vorhanden ist.

Die Haupt-/Grundfunktionen, mit den Typen, Konstanten usw. lege ich auch zusammen in eine Unit
Optionale und zusätzliche Dinge konnen in andere Units.
Im einfachsten Fall muß dann auch nur eine Unit eingebunden werden.

ShowMessage(TLogging.Test(1).ToString);

Zitat:

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen (...) und bei Codevervollständigung und Unitsuche...

Das ist wohl ein Pluspunkt.

Zitat:

Die Haupt-/Grundfunktionen, mit den Typen, Konstanten usw. lege ich auch zusammen in eine Unit
Optionale und zusätzliche Dinge konnen in andere Units.

Das habe ich nicht ganz verstanden. Was konkret würdest du denn in Utils und was in Types packen?

Ich entschuldige mich für all die dummen Fragen. Aber wenn ich bald schon anfange alles umzubenennen und zu verbessern, dann richtig =)

**himitsu**

zusammenfalten · markieren

Delphi-Quellcode:

			Logging.Consts.Internals.pas

Logging.Consts.pas

Logging.Types.Internals.pas

Logging.Types.pas

Logging.Interfaces.Internals.pas

Logging.Interfaces.pas

Logging.Classes.Internals.pas

Logging.Classes.pas

Logging.Utils.pas

Logging.Utils.Database.pas

Logging.Utils.Files.pas

...

uses Logging.Consts, Logging.Types, Logging.Interfaces, Logging.Classes, Logging.Utils, ...;

markieren

Delphi-Quellcode:

			Logging.Internals.pas oder Logging.Base.Internals.pas  // wenn es viel Internes gibt, was nur die Loggingklassen/-funktionen, aber nicht der User nutzt

Logging.Base.pas

Logging.Utils.pas

Logging.Utils.Database.pas

Logging.Utils.Files.pas

...

uses Logging.Base, Logging.Utils, ...;

Wenn du deine Logging-Klasse verwenden willst, dann brauchst du in der Regel auch einige Typen/Enums und eventuell auch 'nen paar Konstanten.

Das sieht verdammt kompliziert aus. Jetzt sind wieder zwei neue dinge hinzugekommen: Base und Internals. Ich wüsste nicht einmal damit etwas anzufangen.
Ich glaube wenn dann bleibe ich bei

Zitat:

Logging.Utils.pas // Funktionen und Prozeduren
Logging.Types.pas // Konstanten, Variablen, Klassen, Records. Eventuell statt "Types" auch "Internals".

Eventuell, wenn es zuviel wird auch

Zitat:

Logging.Utils.NameUnterfunktion // Code, der in Funktionen in Utils ist, Utils auber aufblähen würde, könnte ich dann in NameUnterfunktion auslagern

Aber zur Frage:
dürfen die beiden oben genannten Units weitere Units in der Uses-Klausel stehen haben?

**himitsu**

Wie man seine Grund-Unit nennt, ist vom Prinzip ertmal egal ... da gibt es tausende mögliche Namen.

Zitat von SneakyBagels:

dürfen die beiden oben genannten Units weitere Units in der Uses-Klausel stehen haben?

Natürlich dürfen eingebundene Units in sich beliebig andere Units einbinden.
Nur nicht sich selbst, aber Kreisreferenzen/Kreuzreferenzen sind eh eine eigene unendliche Geschichte.

Aber es ist egal, ob Unit1 auch die Unit2 einbindet.
In deiner Unit hast du dennoch nur direkten Zugriff auf die Unitinhalte, die im Interface der bei dir eingebundenen Units drin sind.

markieren

Delphi-Quellcode:

			// in Unit1.pas

uses Unit2, Unit3, Unit4;

// in deiner Unit

uses Unit1;

Nur Zugriff auf Unit1

markieren

Delphi-Quellcode:

			// in Unit1.pas

uses Unit2, Unit3, Unit4;

// in deiner Unit

uses Unit1, Unit2;

Auch Zugriff auf Unit2.

Ich hab mir auch schonmal sowas wie Unit-Gruppen oder Unit-Makros gewünscht, oder wie man es sonst nennen will.
Also wich dann z.B. nur uses Logging.AllUnits; schreibe und irgendwo ist deffiniert, dass dieses ein "Alias" für Logging.Consts, Logging.Types, Logging.Interfaces, Logging.Classes, Logging.Utils ist.
Da könnte man sich dann Gruppen für KompletteVCLWeilIchkeineLustHabeTausendeUnitsEinze lnEinzubinden, DataSnapUnits, DevExpressUnits, FastReportUnits oder EurekalogUnits anlegen.
Aber das fänden Andere wieder total blöd und extremst sinnlos, siehe die aktuelle

Dateigrößediskusion

Zitat:

Natürlich dürfen eingebundene Units in sich beliebig andere Units einbinden.

Danke. Ich habe mir diese Frage nur gestellt, denn ich dachte immer die Units müssen sauber bleiben, sodass man sie locker flocking von Projekt A nach Projekt B mitnehmen kann.
Das ist bei mir aber schon nicht möglich denn meine Logging-Unit fragt Strings aus einer anderen Unit (Language, mehrsprachiges Programm) ab.
Ist aber glaube ich auch relativ unwichtig hier, denn ich habe eh nur ein Projekt in der Größenordnung.

**jaenicke**

Zitat von SneakyBagels:

Zitat:

Erstmal sind so die zusammengehörigen Dateien auch im Dateisystem zusammen (...) und bei Codevervollständigung und Unitsuche...

Das ist wohl ein Pluspunkt.

Deshalb stehen bei uns die Typen ja wie schon geschrieben in der gleichen Unit. So können wir thematisch gut gruppieren und man muss auch nur eine Unit einbinden. Sobald du das auf mehrere Units aufteilst, bleibt dir wie schon geschrieben nichts anderes übrig als beide Units einzubinden bei der Verwendung. Das macht es deutlich umständlicher.

Sprich eine Unit mit Interface und Typen dazu und eine zweite mit der Klasse, die das Interface implementiert.

Und bezüglich Einbindung anderer Units:
Da gilt nur die Regel bei uns, das gemeinsame Units auch wieder nur gemeinsame Units einbinden dürfen. Sprich keine Units aus bestimmten Projekten.

Zitat:

Sobald du das auf mehrere Units aufteilst, bleibt dir wie schon geschrieben nichts anderes übrig als beide Units einzubinden bei der Verwendung. Das macht es deutlich umständlicher.

Das stimmt natürlich auch.

Ich muss noch gut überlegen was ich mache.
Logging.Utils und Logging.Types wäre natürlich super denn dann wäre alles getrennt und man wüsste in der Unitliste sofort wo man dran ist.

**DevLinus**

Ich strukturiere meine Units so.

markieren

Code:

			rootFolder // Darin alle Forms in der regel mit Allias un davor.

rootFolder/unMain.pas

rootFolder/unSettings.pas

...// Dann kommt ein Fragment ordner falls ich sie nutze.

rootFolder/Fragment

rootFolder/Fragment/Fragment.Header.pas

rootFolder/Fragment/Fragment.Footer.pas

...// Und genau so weiter mit Datamodels und Klassen die irgend einen zusammenhängenden Zweck haben.

rootFolder/Logger/Logger.Utils.pas

rootFolder/Logger/Logger.Typs.pas

....

Finde ich schön übersichtlich und bin ich von Java gewöhnt mit Packages.