Dateien umbennen - welches Namensformat?

[SneakyBagels]

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

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.

Delphi-Quellcode:

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

[SneakyBagels]

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]

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, ...;

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.

[SneakyBagels]

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:

Zitat von SneakyBagels (Beitrag 1375897)

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.

Delphi-Quellcode:

// in Unit1.pas
uses Unit2, Unit3, Unit4;

// in deiner Unit
uses Unit1;

Nur Zugriff auf Unit1

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

Delphi-Quellcode:

uses Logging.AllUnits;

schreibe und irgendwo ist deffiniert, dass dieses ein "Alias" für

Delphi-Quellcode:

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 :stupid:

[SneakyBagels]

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:

Zitat von SneakyBagels (Beitrag 1375888)

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.

[SneakyBagels]

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.

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.