Eine Frage zu "halben" Klassen

[Furtbichler]

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.

[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

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