Ich vermisse Konstanten erst im Konstruktor initialisieren zu können

[Der schöne Günther]

Hallo-

Übersehe ich etwas? Viele meiner Objekte haben Dinge, die einmal im Konstruktor festgelegt werden und sich danach nicht mehr ändern sollen und rein logisch auch nicht können.

Konkretes Beispiel:

Delphi-Quellcode:

THaus.Create(hausNummer:UInt16)

- Das Haus soll eine Konstante auf Instanzebene haben die im Konstruktor initialisiert wird.


Natürlich kann ich es einfach später nicht mehr ändern - Aber da kriege ich Schlafstörungen.

Dann gibt es noch den Compilerschalter J+ mit dem ich grundsätzlich Konstanten überall neu beschreiben kann, aber das ist doch Wahnsinn.


Was tun?
(Wahrscheinlich ist das wieder eine der Fragen die alle paar Monate hier auftauchen, aber ich finde nichts...)

[Sir Rufo]

Wieso Konstante?

Für mich sieht das nach einer Read-Only-Property aus :gruebel:

BTW: alles steht ja irgendwie, irgendwo im Speicher ... als flüchtig und beschreibbar, somit kann alles auf die eine oder andere Art auch überschrieben werden ... einen Schutz gibt es nicht ... gut wenn du dir einen WORM-RAM-Speicher dafür einbaust :mrgreen:

[Phoenix]

In .NET gibts dafür Readonly-Member.

In Delphi könnte das doch über ein (strict) private field in einer Basisklasse gehen, für das es einen protected Property-Accessor (nur read, kein write) gibt.

In jeder Ableitung kannst Du dann nur noch lesend über das Property zugreifen, und es nicht mehr ändern.

[Der schöne Günther]

Danke für die Antworten.

Nur mit Properties unterbinde ich nicht, dass jemand hingeht und in anderen Instanzmethoden (versehentlich) das eigentliche Feld umbriegt, da hilft auch ein

Delphi-Quellcode:

strict private

nicht gegen.

[Lemmy]

hi,

vielleicht versteh ich das Problem nicht, aber wie soll hier jemand in einer abgeleiteten Klasse auf das Private Feld zugreifen:

Delphi-Quellcode:

  TTestBasis = class(TObject)
  strict private
    FTestfeld: Integer;
  strict protected
    property TestFeld: Integer read FTestfeld;
  public
    constructor create(ATest: INteger);
  end;

oder auch umbiegen? Einzig das Property kann man öffentlich machen, ändert aber nichts am Zugriffsschutz (readOnly). In wie weit über die neue RTTI hier auf private Felder zugegriffen werden kann weiß ich allerdings nicht.

[Der schöne Günther]

Zitat:

Zitat von Lemmy (Beitrag 1210759)

hi,

vielleicht versteh ich das Problem nicht, aber wie soll hier jemand in einer abgeleiteten Klasse [...]

Dort natürlich nicht. Aber in der selben Klasse wäre es, ganz banal durch Unwissen oder Unachtsamkeit, möglich.

Ist das schon zu paranoid? Ich fand es in bsp. Java oder C++ eigentlich immer ganz schön, einmal eine Konstante im Konstruktor setzen zu können und mir dann sicher zu sein dass danach nie wieder jemand dran rütteln kann...

[Lemmy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210760)

hi,
Ist das schon zu paranoid? Ich fand es in bsp. Java oder C++ eigentlich immer ganz schön, einmal eine Konstante im Konstruktor setzen zu können und mir dann sicher zu sein dass danach nie wieder jemand dran rütteln kann...

ja - finde ich paranoid :-)

Ich kenne Java/c++ nicht so genau - aber auch wenn du das dort als Konstante definiert hast: was hindert jemand das zu ändern, wenn er deinen kompletten Source hat?

Grüße

[Der schöne Günther]

Das wäre ja schon reine Zerstörungswut :lol:

Mir ging es eher darum, dass jemand nicht aus Versehen später etwas ändert, was sich rein logisch nicht ändern kann. Wie beispielsweise die Adresse auf die ein Gerät antworten soll.

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210762)

Das wäre ja schon reine Zerstörungswut :lol:

Mir ging es eher darum, dass jemand nicht aus Versehen später etwas ändert, was sich rein logisch nicht ändern kann. Wie beispielsweise die Adresse auf die ein Gerät antworten soll.

In der Klasse entsprechend dokumentieren (z.B. an der property) und gut ist

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1210765)

In der Klasse entsprechend dokumentieren (z.B. an der property) und gut ist

:thumb:

Ich finde auch, man sollte nur hinreichend intelligente Programmierer an die Sourcen lassen.

[Der schöne Günther]

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

[TiGü]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210767)

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

Wir SIND gefährlich! 8-)

[stahli]

[nicht so ganz ernst gemeint aber es sollte funktionieren]
Man könnte noch ein privates Flag mit führen: ConstIsNil:=True;

Wird die "Konstante" über einen Setter definiert, wird das Flag auf False gesetzt.
Weitere Zuweisungen über den Setter führen zu einem BlueScreen.

Damit dürfte das Überschreiben der Konstante vermieden werden (außer jemand umgeht bewußt die Kindersicherung).
[/nicht so ganz ernst gemeint aber es sollte funktionieren]

[SubData]

Zitat:

Zitat von stahli (Beitrag 1210774)

[...]
Man könnte noch ein privates Flag mit führen: ConstIsNil:=True;
[...]

Bääh, nee, bitte nicht. Das halte ich ja mal für wirklich dreckig.
Dann lieber sauber kommentieren.

Edit: Ja, ich hab gesehen, dass du das nicht ganz ernst meinst, aber Neulinge klauen sich ja leider immer die blödsten (nicht böse gemeint) Ideen :)

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210767)

Delphi-Programmierer leben wohl gerne gefährlich, was? :-D

Nee, die schreiben zusätzlich Unittests und wenn das ganz wichtig ist, dann wird das der erste Testfall

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1210766)

Ich finde auch, man sollte nur hinreichend intelligente Programmierer an die Sourcen lassen.

Das ist aber extreme Arbeitskraftverknappung!

Gruß
K-H

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1210762)

Mir ging es eher darum, dass jemand nicht aus Versehen später etwas ändert, was sich rein logisch nicht ändern kann. Wie beispielsweise die Adresse auf die ein Gerät antworten soll.

Beim Programmieren sollte man das Gehirn eingeschaltet lassen, tut man das nicht, bekommt man eben unerwartete Ergebnisse.

Wenn du es wirklich absichern willst, setze den Wert im Konstruktor und schreibe dazu eine Prüfsumme des Wertes in ein weiteres privates Feld. Wenn dann jemand beides ändert, ist er selbst schuld. Aber eine versehentliche Änderung könntest du so später erkennen.

[Furtbichler]

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Den Quelltext gibst Du einfach nicht weiter, dann hat sich die Sache erledigt. Dein Problem ist ja ein generelles Problem, welches so gar nicht lösbar ist. Oder hab ich mal wieder irgendwas verpasst?

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1210824)

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Den Quelltext gibst Du einfach nicht weiter, dann hat sich die Sache erledigt. Dein Problem ist ja ein generelles Problem, welches so gar nicht lösbar ist. Oder hab ich mal wieder irgendwas verpasst?

Delphi-Quellcode:

strict private

nur die direkte Klasse kann darauf zugreifen. Weder innerhalb der Unit noch Ableitungen können darauf zugreifen

[DeddyH]

Zitat:

Zitat von Furtbichler (Beitrag 1210824)

'strict private' bedeutet doch, das die Variable nur innerhalb der Unit, in der sie deklariert ist, für abgeleitete Klassen sichtbar ist.

Sicher? Nach meiner Kenntnis ist sie nur in der Klasse sichtbar, zu der sie gehört, aber nicht in abgeleiteten Klassen, selbe Unit oder nicht.

[edit] *Boah eyh*, roter Kasten wieder kaputt (schon das 2. Mal heute) [/edit]

[Sir Rufo]

Diese beiden (Beispiel-) Units sollten veranschaulichen, was geht, und was nicht

Delphi-Quellcode:

unit BaseClass;

interface

type
  TBaseClass0 = class
  strict private
    FStrictPrivate : Integer;
  private
    FPrivate : Integer;
  strict protected
    FStrictProtected : Integer;
  protected
    FProtected : Integer;
  public
    FPublic : Integer;

    procedure DoSomeThing; virtual;
  end;

  TBaseClass1 = class( TBaseClass0 )

  public
    procedure DoSomeThing; override;
  end;

procedure DoSomeThing( ABase : TBaseClass0 );

implementation

{ TBaseClass0 }

procedure TBaseClass0.DoSomeThing;
begin
  FStrictPrivate   := 0;
  FPrivate         := 0;
  FStrictProtected := 0;
  FProtected       := 0;
  FPublic          := 0;
end;

{ TBaseClass1 }

procedure TBaseClass1.DoSomeThing;
begin
  inherited;
  // FStrictPrivate   := 1; // nicht möglich
  FPrivate         := 1;
  FStrictProtected := 1;
  FProtected       := 1;
  FPublic          := 1;
end;

procedure DoSomeThing( ABase : TBaseClass0 );
begin
  with ABase do
    begin
      // FStrictPrivate := 3; // nicht möglich
      FPrivate := 3;
      // FStrictProtected := 3; // nicht möglich
      FProtected := 3;
      FPublic    := 3;
    end;
end;

end.

Delphi-Quellcode:

unit BaseClass2;

interface

uses
  BaseClass;

type
  TBaseClass2 = class( TBaseClass0 )

  public
    procedure DoSomeThing; override;
  end;

procedure DoSomeThing( ABase : TBaseClass0 );

implementation

{ TBaseClass2 }

procedure TBaseClass2.DoSomeThing;
begin
  inherited;
  // FStrictPrivate   := 2; // nicht möglich
  // FPrivate         := 2; // nicht möglich
  FStrictProtected := 2;
  FProtected       := 2;
  FPublic          := 2;
end;

procedure DoSomeThing( ABase : TBaseClass0 );
begin
  with ABase do
    begin
      // FStrictPrivate   := 4; // nicht möglich
      // FPrivate         := 4; // nicht möglich
      // FStrictProtected := 4; // nicht möglich
      // FProtected       := 4; // nicht möglich
      FPublic := 4;
    end;
end;

end.

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1210826)

...

Zitat:

Zitat von DeddyH

...

:wall:
Ich sag ab jetzt nie wieder was. :oops:

[haentschman]

Zitat:

Ich sag ab jetzt nie wieder was.

...joa is denn heut scho Weihnachten ? :mrgreen:

mir war grad so, sorry... 8-)

[Furtbichler]

hmmm. hmmm..mhmmmhmm...hmmhmfgfds:roll: