Hallo zusammen,

ich habe ein paar ältere Threads zu diesem Thema gefunden, wollte aber mal ein kurzes Feedback, ob sich hier etwas geändert hat.

Die Frage ist, was für/gegen eien gemischet Verwendung von Klassen und Records spricht. Hier die beiden Code-Varianten:

zusammenfalten · markieren

Delphi-Quellcode:

Type
  TPosition = record
    X, Y, Z: Integer;
  end;

  TTest = class
  private
    FNr: Integer;
    FName: String;
    FPosition: TPosition;
    procedure SetNr(iNumber: Integer);
  public
    property Nr: Integer read FNr write SetNr;
    property Name: String read FName write FName;
    constructor Create;
    destructor Destroy; override;
  end;

oder die reine Klassen-Variante

zusammenfalten · markieren

Delphi-Quellcode:

Type
  TPosition = Class
    FX, FY, FZ: Integer;
  public
    property X: Integer read FX write FX;
    property Y: Integer read FY write FY;
    property Z: Integer read FZ write FZ;
    constructor Create;
    destructor Destroy; override;
  end;

  TTest = Class
  private
    FNr: Integer;
    FName: String;
    FPosition: TPosition;
    procedure SetNr(iNumber: Integer);
  public
    property Nr: Integer read FNr write SetNr;
    property Name: String read FName write FName;
    constructor Create;
    destructor Destroy; override;
  end;

Ich sehe in der zweiten Variante zunächst vor allem den Mehraufwand

• in der Deklaration
• dass ich auch für TPosition zusätzlich Create/Destroy aufrufen muss

Vorteile sehe ich eigentlich nicht.

TTest steht nicht zur Diskusion. Hier habe ich in obigem Code nur einen Bruchteil der Funktionalität dargestellt.

Danke für euer Feedback
Gerd

Dein TPosition ist ein sogenanntes Value Object.

Berücksichtigt man deren Eigenschaft der Unveränderbarkeit (ich kann nicht einfach nur X, Y oder Z ändern) merkt man bei der Speicherverwaltung von Delphi, dass man sich dann oft um das Freigeben, des vorherigen Objekts kümmern muss, wenn man eine neue TPosition erzeugt und zuweist. Daher bietet sich hierfür eher die Verwendung von Records an. (bei Sprachen mit GC oder anderer automatischer Speicherverwaltung ergibt sich dieses Problem nicht, daher werden dort auch oft Klassen statt Records/Structs benutzt)

Außerdem kann man bei Records einfacher implizite oder explizite Typkonvertierung durch Operatorüberladung einbauen.

Das könnte zur Folge haben, dass man auch beim Record private Felder, öffentliche readonly Eigenschaften und ggf einen Konstruktor benutzt.

Gerne wird vergessen, dass in Delphi auch Folgendes für Records möglich ist:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TPosition = record
  private
    FX, FY, FZ: Integer;

    procedure SetX(const Value: Integer);
    procedure SetY(const Value: Integer);
    procedure SetZ(const Value: Integer);
  public
    property X: Integer read FX write SetX;
    property Y: Integer read FY write SetY;
    property Z: Integer read FZ write SetZ;
  end;

Damit hat man dann auch Kontrolle über Veränderungen - in diesem Beispiel wahrscheinlich nicht sinnvoll, aber man sollte es im Hinterkopf haben. Und dann sind Records wirklich ein praktisches Mittel für die Value Objekte.

......

Zitat von sakura:

man sollte es im Hinterkopf haben. Und dann sind Records wirklich ein praktisches Mittel für die Value Objekte.

Gerade nicht, Value Objekte sind per Definition unveränderlich, d.h. es gibt keine Setter um einzelne Eigenschaften zu ändern.
Was im Zusammenhang mit Records auch gut ist, da es so nicht so Code wie diesem kommen kann:

test.Position.X := test.Position.X + 10; Und man sich dann wundert, warum es nicht mehr funktioniert nachdem man für die Position Eigenschaft einen Getter geschrieben hat
(weil man nun X einer Kopie - Records sind Value types - ändert)

Ich bin jetzt vielleicht blöd, aber wieso ist TPosition ein ValueObject?

Sherlock

Zitat von Sherlock:

Ich bin jetzt vielleicht blöd, aber wieso ist TPosition ein ValueObject?

Der deutsche Wikipedia Eintrag ist da möglicherweise nicht so klar wie die englische Beschreibung:

Zitat von en.wikipedia.org:

In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.

Bei einer Position ist in aller Regel: (4,5,6) = (4,5,6) auch wenn das zwei unterschiedliche Instanzen/Entitäten sind. Wenn nun aber 2 Objekte in einem Koordinatensystem an derselben Position sind und eins davon sich ändert, weise ich ihm eine neue Position zu (auch, wenn sich nur X, Y oder Z geändert hat). Hätte ich möglicherweise Objekte dafür, ergäbe sich die Gefahr, dass es sich um dieselben Instanzen handelt, weil ich irgendwo geschrieben habe:

markieren

Delphi-Quellcode:

pos := TPosition.Create(4, 5, 6);
obj1.Pos := pos;
obj2.Pos := pos;

Angenommen ich habe nun noch Setter für X, Y, Z. Wenn ich nun obj1.Pos.X := 7; schreibe, ändert sich dann die Position von obj2 möglicherweise auch.

Zitat von Stevie:

Gerade nicht, Value Objekte sind per Definition unveränderlich, d.h. es gibt keine Setter um einzelne Eigenschaften zu ändern.

Sorry, stimmt. Aber gerade da ist es dann sinnvoll diese einmalig zu initialisieren und dann die Werte nur noch über read-only Properties zu ermitteln.

zusammenfalten · markieren

Delphi-Quellcode:

type
  TPosition = record
  private
    FX, FY, FZ: Integer;
  public
    class function New(const aX, aY, aZ: Integer): TPosition; static;

    property X: Integer read FX;
    property Y: Integer read FY;
    property Z: Integer read FZ;
  end;

class function TPosition.New(const aX, aY, aZ: Integer): TPosition;
begin
  Result.FX := aX;
  Result.FY := aY;
  Result.FZ := aZ;
end;

......

Danke, Stevie!

Sherlock