Private/Public in Unit mit gesammelten Funktionen ala Math

[Jumpy]

Hallo,

ich möchte mir eine Unit erstellen, in der ich so alle möglichen Funktionen packen wollte, die ich so gelegentlich brauche. Vllt. werden's auch mehrere Units, thematisch sortiert.

Da sollen keine Klassen drin entstehen, sondern wirklich nur Funktionen. Im Prinzip also sowas wie die Unit Math.

Sind in so einer Unit alle Funktionen public? Oder kann man da auch Funktionen zum internen Gebrauch in der Unit ablegen, die aus anderen Units heraus nicht aufgerufen werden können? In der Unit Math, die ich mir als Beispiel angeguckt habe, stand im Interface-Bereich nirgendwo was von private und public...

[DeddyH]

Alle Funktionen, deren Funktionsköpfe im interface-Teil stehen, sind von außen erreichbar. Alle anderen nicht.

Delphi-Quellcode:

unit Dings;

interface
  
uses ...;

function Func1: integer; //von außen aufrufbar

implementation

function Func1: integer;
begin
  ...
end;

function Func2: integer; //nur Unit-intern benutzbar
begin
  ...
end;

[himitsu]

Alles was im "interface" veröffentlicht wird, ist puclic.

Alles was nur in der "implementation" auftaucht, ist quasi private.

[edit]
Ich wünschte mir eine rote Box.

[Uwe Raabe]

Eine Methode, die im Imterface-Teil deklariert wird, ist public. Es hindert dich aber niemand daran, eine Methode nur im Implementation-Teil zu platzieren - dann ist die private. In der Unit Math bei D5 sind das z.B. die Methoden Annuity2, ArgError, CoshSinh, PaymentsParts, PolyX, RaiseOverflowError, RelSmall und der Record TPoly.

[DeddyH]

Wer will nochmal, wer hat noch nicht? :lol:

[shmia]

Zitat:

Zitat von DeddyH (Beitrag 1173689)

Wer will nochmal, wer hat noch nicht? :lol:

Ich, Ich, Ich!

Zitat:

Vllt. werden's auch mehrere Units, thematisch sortiert.

Unbedingt nach Thema sortieren!
Diese "Utility"-Units in denen querbeet alles Mögliche enthalten ist sind Müll.

Aber bevor du deine eigenen Units erstellst wäre es ratsam zu schauen, ob es das was du brauchst nicht irgendwo schon gibt.
Und was soll ich sagen - natürlich gibt es das schon.
JEDI Code Library

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1173689)

Wer will nochmal, wer hat noch nicht? :lol:

Schon gut, irgendwie mag mich der rote Kasten manchmal wohl nicht so richtig.

[Medium]

Für sowas nehme ich mir auch gerne Klassen, die ausschließlich "static" Methoden ("class function" etc.) beinhalten. Dadurch ist man angenehm gezwungen thematisch sinnvoll in diesen Klassen zu gruppieren, hat Felder (statt globals), und hat bei der Verwendung gleich einen hübsch qualifizierten Namen.

[DeddyH]

Zitat:

Zitat von Uwe Raabe (Beitrag 1173694)

Schon gut, irgendwie mag mich der rote Kasten manchmal wohl nicht so richtig.

Das sollte auch kein Kritik sein, nur 3 Mal die sinngemäß in etwa gleiche Antwort nacheinander fand ich schon irgendwie witzig. Nix für ungut.

[himitsu]

Delphi 6 sollte doch auch schon Klassenfunktionen unterstützen?

Delphi-Quellcode:

type
  TUtilityXyz = class // in neueren Delphis "class abstract" oder als Record
    class function Max(x, y: Integer): Integer; static; // wenn static noch nicht geht, dann weglassen
    class function Min(x, y: Integer): Integer; static; overload;
    class function Min(x, y: Double): Double; static; overload;
  end;

Mit Static ist es vom Funktionsaufruf her, wie eine ganz billige Function/Prozedur, nur daß man auf diese Weise auch Mehreres in einer Unit unterbringen und gruppieren kann.
(Klassenname als Namespace, anstatt mehrere Units/Unitnamen)

[Jumpy]

Zitat:

Zitat von himitsu (Beitrag 1173687)

Alles was im "interface" veröffentlicht wird, ist puclic.
Alles was nur in der "implementation" auftaucht, ist quasi private.

Hab mal nur himitsu zitiert, da's am kürzesten war :-)

Danke für die Aufklärung, hätt ich auch selber drauf kommen können. Hatte mich eh schon gewundert, warum im implementation Teil nochmal nur Funktionsrümpfe mit 'ner Vorwärtsdeklaration standen, aber das macht ja dann Sinn, wenn diese Funktionen erst noch weiter unten implementiert, aber schon weiter oben gebraucht werden.

Hatte schon gedacht mir mit dem Konstrukt der Funktion in einer Funktion zu helfen, ala:

Delphi-Quellcode:

function ABC:String;
function Hilfsfunktion:String;
begin
//Mach was
end;
begin
//Mach was und ruf dabei Hilfsfunktion auf
end;

Aber das wäre spätestens dann blöd geworden, wenn ich eine Hilfsfunktion in einer weiteren Funktion ein zweites mal hätte brauchen können. Zudem finde ich diese Konstruktion immer unübersichtlich, da sie oft auch dazu führt, das eine Funktion über mehr als eine Bildschirmseite geht (versuch ich immer zu vermeiden).

@shmia:
Idee ist Prozeduren, die ich mal häufiger brauche an einer(?) Stelle zusammenzufassen. Nur als Bsp.: Ich brauche aus Math eigentl. immer nur Max und Min. Binde aber jedes mal komplett Math dafür ein. Soll quasie sowas wie meine Top10-Tools-Sammlung werden.

[himitsu]

Forwad kann man auch in der Implementation benutzen.

Delphi-Quellcode:

function XYZ: string;
  forward;

function ABC: string;
begin
  Result := XYZ;
end;

function XYZ: string;
begin
  Result := ABC;
end;

Delphi-Quellcode:

interface

function ABC:String;

implementation

function Hilfsfunktion:String;
begin
//Mach was
end;

function ABC:String;
begin
  Resulz := Hilfsfunktion;
end;

"neuere" Delphis (seit mindestens 2006) können auch Typen verschachteln. (engebettete Typen, oder wie man das nennt)

Delphi-Quellcode:

interface

type
  TPublicClass = class
  private type
    TPrivateClass = class
    end;
  private
    function PFunc: TPrivateClass;
  public

  end;

implementation

type
  TUnitPrivate = class
  end;