nochwas zum Thema .Identity im
DEC. Das ist eine der Stellen dir mir so garnicht noch nie richtig gefallen hat
Die zu lösende Problematik ist eine möglichst kurze aber eineindeutige ID zu jeder Klasse im
DEC zu schaffen. Wichtig dabei ist aber noch das man mit der Änderung von DECUtil.IdentityBase alle IDs serialisieren kann. Dh. je nach Anwendung kann der Programmierer über IdentityBase das ID System individualisieren auf ein Projekt ohne das man den kompletten Source ändern muß.
Man speichert also in einem Stream als Header die Identities der benutzten
DEC Klassen und danach zb. die verschlüsselten Daten. Bei der Entschlüsselung kann mit DECClassByIdentity() diese registrierte Klasse als Objekt geladen werden. Um diese Header mit fester Länge anlegen zu können wird für Identity ein Cardinal benutzt, statt wie üblich den Klassennamen im Header lesbar zu speichern.
Ein weiteres Kriterium war dabei aber auch das zukünftige neue
DEC Klassen voll transparent implementierbar sein müssen ohne das sich der jeweiligen Programmierer mit diesen IDs beschäftigen müssen. Zb. bei Vergabe fester sequentieller IDs für die Klassen müssen die Programmierer sich immer abstimmen und diese IDs dann auch pflegen. Das geht bei einer Bibliothek die weltweit verwendet wird leider nicht mehr zu organisieren.
Jetzt, im nachhinein, würde ich GUIDs dafür benutzen da man damit schon rein mathematisch die Wahrscheinlichkeiten von Kollisionen enorm reduziert. Das jetztige Verfahren birgt ein hohes Risiko von Kollisionen, die aber bei der Registration einer
DEC Klasse zuverlässig erkennt werden. Sollte dies der Fall sein muß man entweder den Klassennamen oder IdentityBase ändern.
Wie gesagt, damals viel mir nichts besseres ein und zufrieden bin ich mit dieser Lösung noch heute nicht. Vielleicht fällt ja einem von euch was ein was neu für mich wäre.
Gruß Hagen