Im Constructor die Instanz zerstören

[Kostas]

Hallo Zusammen,

ich habe eine Klasse dessen Constructor ein Datenpaket als Parameter bekommt.
Im Constructor wird eine private Methode aufgerufen die das Paket überprüft.
Falls das Paket fehlerhaft ist, soll die Instanz gleich zerstört werden
sprich das Objekt soll null sein.

Wie macht man das am saubersten?

Gruß Kostas.

[Dawn87]

Du könntest über eine statische Methode sicherstellen, dass Du das Objekt erst dann erzeugst, wenn der Eingangsparameter gültig ist. Ansonsten ist es möglich im Constructor eine Exception zu werfen.

[himitsu]

Eigentlich solltest du das besser vorher prüfen,

ansonsten löst du eben eine Exception aus, diese beendet dann den Constructor und ruft automatisch den Destructor auf.



Oder eben die erwähnte (statische) Funktion "Parameter prüfen, wenn OK, die Instanz erstellen und zurückgeben"

[Dejan Vu]

Zitat von Kostas:

Wie macht man das am saubersten?

Gar nicht. Logik gehört nicht in den Konstruktor. Damit man sich eben diese Fragen erst gar nicht stellt.

Schreibe einen Setter für das Datenpaket, in dem Du das Paket auf Korrektheit prüfst und wirf eine Exception, wenn dir das Paket nicht passt.

Delphi-Quellcode:

Type
  TMyClass = Class
  Private
    fPacket : TDataPacket;
    Procedure DemandValidPacket(Const aValue : TDataPacket);
    Procedure SetPacket(Const aValue : TDataPacket);
  public
    Constructor Create;
    Property DataPacket : TDataPacket Read fPacket Write SetPacket;
  End;

Procedure TMyClass.DemandValidPacket(Const aValue : TDataPacket);
Begin
  if not aValue.IsValid then Raise EInvalidData.Create('Invalid Datapacket');;
End;

Procedure TMyClass.SetPacket(Const aValue : TDataPacket);
Begin
  DemandValidPacket(aValue);
  fPacket := aValue;
End;
//
...
Var
  myClass : TMyClass;
Begin
  myClass := TMyClass.Create;
  Try
    myClass.DataPacket := TheDataPacket;
    ...
  Finally
    myClass.Free;
    raise;
  End
End;

[Kostas]

Tausend Dank für den Hinweis.

Die Prüfung kann nicht über eine statische Methode erfolgen da es viele
Abhängigkeiten gibt. Die Decodiermethode habe ich aktuell public und befülle
die Felder des Objects aus dem Paket. Falls irgend wo eine exception ausgelöst wird, wird das Objact zerstört. Ich dachte mir dabei nur, ein Object mit einem
defekten Datenpaket darf es nicht geben den das Object repräsentiert genau
das entschlüsselte Datenpaket. Deshalb die Frage ob es sinnig ist gleich im
Constructor zu dekodieren und ggf. das Object erst gar nicht erzeugen zu lassen.

ok, das ist also Unsinn.

Ich belasse es so wie es ist.

Dankeschön. Gruß Kostas

[Sir Rufo]

Die Pakete müssen ja bestimmte Sezifikationen/Kriterien erfüllen.

Dann baut man eben so eine Sezifikation zusammen und jagt das Paket durch die Spezifikationen und bekommt so heraus, ob es passt.

Schau dir mal dieses Java-Konstrukt an (alles was Specification im Namen hat)
https://svn.code.sf.net/p/dddsample/...domain/shared/
Das kann man auch sehr einfach mit Delphi zusammenbauen und damit die unterschiedlichsten Spezifikationen zusammenstecken ohne sich wiederholen zu müssen (DRY)

[himitsu]

Zitat von Kostas:

Deshalb die Frage ob es sinnig ist gleich im
Constructor zu dekodieren und ggf. das Object erst gar nicht erzeugen zu lassen.

ok, das ist also Unsinn.

Im Constructor ist die Instanz bereits erstellt und wird dort nur noch mit dem eigenen Code initialisiert.

[Kostas]

Zitat von Sir Rufo:

Die Pakete müssen ja bestimmte Sezifikationen/Kriterien erfüllen.
...
(DRY)

Das Paket ist genau Spezifiziert und wird als ein Array of Bytes übergeben.
Das Paket auf Gültigkeit zu prüfen ist sehr umfangreich. Das sind Maschinen Pakete. Jedes Paket beginnt mit ein Byte Paket-Identifier $44 also ein "D" danach folgen ein paar Bytes als Nutzdaten und danach ein paar Bytes für den FeldSelektor.
Darüber erfahre ich welche weitere Felder im Paket enthalten sind. Die Felder haben unterschiedliche jedoch definierte Längen, bis auf das letzte Feld welches eine nicht definierte Länge hat. Die Feldreihenfolge ist Fix. Ich muss mich also von oben nach unten durchhangeln. Wenn ein Feld laut FeldSelektor enthalten ist, dann kann ich es verarbeiten und den Positionsindex um die Feldlänge incrementieren.

Um diesen Misst vorher zu prüfen muss ich wirklich viel Arbeit investieren.
Deshalb verlasse ich mich einfach darauf dass das Paket in sich schlüssig
ist und greife ohne zu prüfen auf die Bytes zu.
Und wenn es mal Knallt, dann war das Paket doch nicht korrekt.

Laut Spezifikation werden ausschließlich korrekte Pakte versendet. Ich darf
mich also verlassen dass die Pakete in sich schlüssig sind. Nur im Falle
eines Kommunikation Konfliktes kann es defekte Pakete geben. Ein Langzeittest wird zeigen wie Wahrheitsgetreu die Aussage ist.

Gruß Kostas

[Sir Rufo]

Die Spezifikationen lesen sich auf den ersten Blick kompliziert.

Wenn man diese allerdings in die einzelnen Teilaspekte unterteilt, die ausschließlich das testen

1. Startet mit $44
2. Beinhaltet 2 Felder
3. Beinhaltet Feld a
4. Beinhaltet Feld b
5. Beinhaltet Feld c
6. Feld b ist im Bereich von 50-100
7. ...

dann kann man sich daraus Spezifikationen für die einzelnen erwarteten Nachrichten zusammenstecken:

1. A und C und nicht D und E
2. A und B und F und C und D

Die Gesamtspezifikation (prüfe ob die Nachricht überhaupt gültig ist) ist nun

Code:

(a oder b)

[Dejan Vu]

Man kann natürlich jedes Paket im Vorfeld validieren, allerdings kann man davon ausgehen, das die Pakete in der Regel korrekt sind, vor allen Dingen deshalb, weil anzunehmen ist, das der Kommunikationspartner immer der gleiche ist. Fehler, d.h. Gründe für eine Validierung, sind ja immer am Anfang der Zusammenarbeit zu erwarten.

Das heißt natürlich nicht, das man keine Fehler abfangen soll, aber ich denke, es genügt vollkommen, die Prüfung während der Abarbeitung durchzuführen, allerdings nur dann, wenn der Abbruch der Verarbeitung auf Grund eines Fehlers nicht zu Inkonsistenzen führt. D.h. wenn man bei der Abarbeitung schon weitere, nicht rücknehmbare Operationen vornimmt, muss das Paket vorher validiert werden.

Die Validierung wird sich natürlich negativ auf die Performance auswirken.