Ich bringe einem gerade privat ein wenig Delphi bei und es kam eine Frage auf die ich keine zufriedenstellende Antwort geben kann bis auf, dass man es so macht. Ein Beispiel:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TTest = class
    a: Boolean;
    constructor Create;
  end;

constructor TTest.Create;
begin
  inherited Create;
  a := True;
end;

Ich hab die Sichtbarkeit anhand der Formularklassen erklärt und da landen die Komponenten in keinem Abschnitt. Mir fehlte die Erklärung warum.

Private, public, protected usw. konnte ich erklären, wird auch akzeptiert, was aber wenn es unwichtig ist?

Weil 'public' implizit angenommen wird?

Die Komponenten sind published, das wird in diesem Fall nur nicht davorgeschieben. Und das ist gar nicht unwichtig, ganz im Gegenteil, denn sonst könnten beim Erstellen der Formulare die Eigenschaften aus den DFM-Dateien nicht zugewiesen werden. Probier es einfach mal aus und schreibe ein public vor die Komponenten.

Der Standard ist Public, aber wurde die Klasse oder ein Vorfahr mit dem Kompilerschalter {$M+} kompiliert (z.B. TControl und somit auch TComponent und die ganze VCL), dann wird die Grundeinstellung auf Published geändert, für diese Komponenten/Klassen.

Und das Published macht auch ein paar Probleme ... z.B. bei überladenen Methoden.

markieren

Delphi-Quellcode:

strict private // ist wirklich privat
private // entspricht unitintern eher einem public
strict protected // ist wirklich protected
protected // entspricht unitintern eher einem public
public // ab hier lohnt sich strict nicht, da es eh schon global ist, also gibt's das auch nicht
published

Zitat:

und da landen die Komponenten in keinem Abschnitt.

Doch, tun sie ... in dem, was standardmäßig definiert wurde.
Man könnte es also auch selber angeben. (nur blöd, daß der VCL-Parser so doof ist)


Der Grund wurde auch schon genannt.
Die VCL, genauer der DFM-Loader geht immer über die "alte" RTTI und dort sind standardmäßig nur für Published Property und Methoden die Informationen vorhanden.
Nur Published-Property, also speziell Eventmethoden und Komponenten-Variablen können verarbeitet werden, was für das Laden der DFM notwendig ist.

Zitat von Popov:

..bis auf, dass man es so macht.

Ich würde es so *nicht* machen, denn man sieht nicht, welcher Zugriffsrestriktion die Eigenschaften denn nun unterliegen

Zitat:

....Private, public, protected usw. konnte ich erklären, wird auch akzeptiert, was aber wenn es unwichtig ist?

Unwichtig ist es nie.

Was mich angeht, erstelle ich schon seit Ewigkeit einfache Klassen um sie an Objekte anzuhängen, ein Beispiel:

markieren

Delphi-Quellcode:

type
  TInfo = class
    Filename: String;
    Path: String
  end;

Ich sehe da keine Notwendigkeit sie komplexer zu gestallten wenn es nicht sein muß. Ein Objekt des oberen Typs kann ich z. B. in einer ListBox nutzen. Welchen Mehrwert hat das?

markieren

Delphi-Quellcode:

type
  TInfo = class
  private
    FFilename: String;
    FPath: String;
  public
    property Filename: string read FFilename write FFilename;
    property Path: string read FPath write FPath;
  end;

Ich glaube nicht, dass ich je eine weitere Klasse daraus ableite.

Zitat von Popov:

Ich sehe da keine Notwendigkeit sie komplexer zu gestallten wenn es nicht sein muß.

Och, ein einfaches 'Public' ist nicht gerade 'komplexer'.

Zitat von Popov:

markieren

Delphi-Quellcode:

type
  TInfo = class
  private
    FFilename: String;
    FPath: String;
  public
    property Filename: string read FFilename write FFilename;
    property Path: string read FPath write FPath;
  end;

Ich glaube nicht, dass ich je eine weitere Klasse daraus ableite.

Ich schon. Wo ist Erstellungsdatum, Dateigröße etc.? Und bitte nicht "dann erweitere ich eben die Klasse", denn: Man soll Klassen so schreiben, das sie nicht erweitert werden müssen (open/closed Prinzip).

Ebenso sollte man ordentlich und sauber programmieren (finde ich). Also sind -bei mir zumindest- Sätze wie "werd ich nie erweitern", "sieht man doch", "braucht man eh nicht" beim Programmieren fehl am Platze (Self documented code)

Ergo kommt bei mir immer ein explizites "public" hin, auch wenn es vielleicht überflüssig ist. Ich gehe immer davon aus, das jemand anders meinen Code lesen muss und ich habe den Anspruch an meinen Code, hinterher keine Fragen beantworten zu müssen.

1.) es war nur ein Beispiel auf die Schnelle

2.) ich bin nicht dagegen und akzeptiere durchaus den Wunsch nach saubere Programmierung. Ein public macht es sicherlich nicht komplexer, es geht hier eher drum was geht und was falsch ist. Wenn ich das T bei einer Klasse weg lasse, dann ist es kein Fehler, ich verletze eher eine allgemeine Regel.

Spätestens dann, wenn man merkt, dass eine Plausibilitätsprüfung Sinn macht, wird man fluchen, wenn man die Felder der Klasse "mal eben" einfach so veröffentlicht hat, anstatt Properties zu deklarieren. Wenn man die Klassenvervollständigung nutzt, hat man dabei nur unwesentlich mehr Tipparbeit, dafür aber gleich eine saubere Struktur, in der man kurz den Setter erweitert und glücklich sein darf.

Zitat von DeddyH:

Spätestens dann, wenn man merkt, dass eine Plausibilitätsprüfung Sinn macht, wird man fluchen, wenn man die Felder der Klasse "mal eben" einfach so veröffentlicht hat, anstatt Properties zu deklarieren. Wenn man die Klassenvervollständigung nutzt, hat man dabei nur unwesentlich mehr Tipparbeit, dafür aber gleich eine saubere Struktur, in der man kurz den Setter erweitert und glücklich sein darf.

Gleichnamige Property einbauen, privates Feld hinzufügen, Setter implementieren, neu compilieren und fertig
(Probleme gibt's eigentlich nur, wenn man ausgiebig von der RTTI Gebrauch macht, oder andere Programmteile nicht neu compiliert werden können...)