Eine Frage zu "halben" Klassen

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

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

[DeddyH]

Zitat von jfheins:

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

Du bist mein Held

[jfheins]

Zitat von DeddyH:

Du bist mein Held

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.

[Furtbichler]

Zitat von DeddyH:

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.