Eine Frage zu "halben" Klassen

[Popov]

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:

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?

[Furtbichler]

Weil 'public' implizit angenommen wird?

[Peter1999]

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.

[himitsu]

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.

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. :zwinker:
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.

[Furtbichler]

Zitat:

Zitat von Popov (Beitrag 1167286)

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

[Popov]

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

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?

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.

[Furtbichler]

Zitat:

Zitat von Popov (Beitrag 1167308)

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

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

Zitat:

Zitat von Popov (Beitrag 1167308)

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.

[Popov]

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.

[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.

[jfheins]

Zitat:

Zitat von DeddyH (Beitrag 1167317)

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 :mrgreen:
(Probleme gibt's eigentlich nur, wenn man ausgiebig von der RTTI Gebrauch macht, oder andere Programmteile nicht neu compiliert werden können...)

[DeddyH]

Zitat:

Zitat von jfheins (Beitrag 1167318)

Gleichnamige Property einbauen, privates Feld hinzufügen, Setter implementieren, neu compilieren und fertig :mrgreen:

Du bist mein Held :roll:

[jfheins]

Zitat:

Zitat von DeddyH (Beitrag 1167319)

Du bist mein Held :roll:

Falls es dich beruhigt, ich benutze auch eher Properties statt öffentliche Felder. Bei mir sieht das dann aber meistens so aus:

Code:

        public int ID { get; set; }
        public string Name { get; set; }
        public List<string> Fach { get; set; }

Das ist dann doch schon erheblich weniger Schreibarbeit (insb. mit dem prop-Makro) als die Delphi-Variante.

[DeddyH]

Ist mir bekannt (Get und Let soll es ja auch noch geben, in so "komischen" Sprachen). Mir ging es nur darum, dass man sich genau das beschriebene Vorgehen dann eben nicht antun muss, wenn man gleich mit Properties arbeitet.

[Furtbichler]

Zitat:

Zitat von DeddyH (Beitrag 1167317)

Spätestens... wird man fluchen, wenn man die Felder der Klasse "mal eben" einfach so veröffentlicht hat, anstatt Properties zu deklarieren

Mach aber nicht den Fehler, daraus ein Dogma zu machen. Bei Data Transfer Objects ist es totaler Overkill.

Es ist -auch aus Sicht des Clean Code- durchaus legitim und sogar erwünscht, Felder direkt zu publizieren, wenn es der Lesbarkeit und Klarheit des Codes dient. Wobei dies bei Businessobjekten (also die, die ein Verhalten implementieren) wohl nicht auftreten wird, sondern eben auf die erwähnten DTO oder VO beschränkt bleibt.

[edit] Popov, nun habe selbst ich kapiert, worauf deine Eingangsfrage abzielt (oder?): Sind DTO's legitim?
Ich würde sagen: Ja, aber nicht, wenn dein Umfeld nicht mitspielt. Aus der Sicht des OOP ist es jedenfalls nicht verboten. In diesem Forum würdest Du aber mit dem DTO-Konzept vielleicht Probleme bekommen.. ;-)

[Popov]

Es ist wie gesagt, ich versucht einem gerade das Thema beizubringen, aber um genau zu sein habe ich mich damit nie auseinender gesetzt, vielmehr folgte ich der Herde. Dass ich Klassen mit direkt publizieren Feldern habe, ist hat so.

Ich weiß nicht ob es didaktisch unbedingt von Nöten am Anfang gleich mit private, public usw. zu kommen, ich denke die Einsicht kommt von alleine später. Man behandelt da die Sichtbarkeiten noch bevor einer weiß wie Klassen arbeiten. Das ist wie bei Fahrschule parken lernen noch bevor man zum ersten Mal gefahren ist. Ich weiß aber nicht ob es richtig ist.

Insoweit würde mich der Unterschied interessieren was ok, was besser und was ein Muß ist. Ich bin der Meinung, dass es ok direkt auf Felder zuzugreifen, es aber besser ist sie privat zu deklarieren. Ist aber nur meine Meinung, ob es so ok ist, weiß ich nicht.

Edit:@Furtbichler sein Edit

Das beantwortet schon zum Teil meine Frage. Ich betrachte es aber nicht unbedingt als ein Konzept, vielmehr was möglich oder nötig ist.

[mkinzler]

Ich würde es nicht als Einparken, sondern mit den Verkehrsregeln gleichsetzen. Diese sollte man vor dem Fahren kennen.

[Popov]

Also das mit dem Einparken war schon bewusst gewählt. Ich hab zu diesem Thema einige Tutorials überflogen, nur um zu sehen, und allen scheint das Thema so wichtig zu sein, dass sie es als erstes behandeln. Dann ist mir eingefallen, dass ich zwei Bücher habe, das eine hat es als mittleres Thema, das andere noch weiter hinten.

Ich will keinen kritisieren, aber didaktisch sind einige Tutorials nicht gerade aufgebaut. Und was das Fahren angeht, keine Ahnung wie es heute ist, ich war mit dem Fahrlehrer auf der Straße noch bevor ich die Verkehrsregeln kannte ;)

[himitsu]

Die Reihenfolge ist halt nicht immer ganz leicht.

Ich würde auch das Debuggen und einige IDE-Funktionen relativ weit vorne ansiedeln.
Praktisch noch vor den ersten Programmierversuchen, denn ab dann passieren ja schließlich nur noch Fehler und diese möchte man dann auch ordentlich behandeln können.