Constraint über Doku oder Interface?

[Dravere]

Hallo zusammen,

Ich habe aktuell eine eigene Collection geschrieben, worin man Objekt ablegen kann. Damit die Constraints korrekt bleiben, dürfen diese Objekte allerdings nicht verändert werden, nachdem sie in die Collection eingefügt wurden.

Mein Problem ist nun, wie stelle ich das vernünftig an? Soll ich ein ICloneable<T> Interface verwenden, welches implementiert werden muss und somit automatisch Kopien ablegen und auch nur Kopien zurückgeben? Oder sollte ich sowas einfach nur in die Dokumentation schreiben?

Was empfehlt ihr?

Die Collection wird voraussichtlich nur sehr einfache Objekte enthalten, welche auch sehr leicht kopierbar sind. Heisst die Klassen bestehen jeweils nur aus primitive Typen.

Grüssli

[*rant*]

Ich habe dieses Problem schon oft gehabt, allerdings recht tief in der Applikation, so dass es kein Problem war. In diesen Fällen habe ich es dann einfach irgendwie dokumentiert.

Falls du die Constraints nach aussen durchsetzen möchtest: Wäre es für dich nicht eine Möglichkeit, die Objekte als immutable zu designen? Das wäre das einfachste und performanteste, was du tun könntest. Die Sache mit ICloneable<T> finde ich allerdings auch recht toll; das kann man auch schön als Constraint auf T angeben.

MfG

[Gast]

ICloneable finde ich nicht so toll.
Dann müsste auch verlangt werden, dass Equals oder IEqualityComparer sauber implementiert ist für alle Typen. Eigentlich verlässt man sich bei Collections ja oft auf Referenzgleichheit der Objekte die man einfügt, bei Methoden wie Contains oder LINQ.

Ich würde es wahrscheinlich einfach dokumentieren und der Verantwortung des Benutzers überlassen. Das Framework macht es auch nicht anders bei HashSet oder SortedList.

[Firefighter]

Willst du das Constraint zur Compile-Time abfackeln? Weil dann bringt dir das nichts es in der Doku zu erwaehnen.

[xxox]

where T: struct

[Dravere]

/rant/ schrieb:

Falls du die Constraints nach aussen durchsetzen möchtest: Wäre es für dich nicht eine Möglichkeit, die Objekte als immutable zu designen?

Ich möchte die Collection als Teil einer Art Utility Bibliothek anbieten. Heisst, dass ich fast nichts darüber bestimmen kann, was für Objekte da abgelegt werden. Ich müsste sowas also in die Doku aufnehmen.

@µ,
Ja, im .Net Framework wird es so gemacht. Aber ich empfinde dies als wahnsinnig fehleranfällig. Das kann dann auch zu unglaublich schwer auffindbaren Fehlern führen. Unterschiedliche Collections können untereinander verbunden werden und haben dann Abhängigkeiten zueinander. Wenn eine Collection fehlerhaft ist, kann sich das auf alle anderen auswirken. Der Fehler kann plötzlich sonstwo auftreten.
In SortedSet , HashSet , usw. habe ich bisher meistens nur primitive Typen abgelegt (Bei SortedDictionary und co primitive Typen als Keys), heisst vor allem immutable Typen. Daher bin ich noch nie über so einen Fehler gestolpert. Aber hier werden mit ziemlicher Sicherheit keine primitiven Typen abgelegt werden. Und die Chancen sind sehr gut, dass sie mutable sein werden.

@Firefighter,
Abfackeln? Ich möchte eigentlich meinen Code nicht anzünden
Meinst du abwickeln? Da bringt es mir auch nichts ICloneable<T> anzugeben, weil bei Clone jemand immer noch this zurückgeben könnte. Compile-Time Sicherheit kann ich fast vergessen, aber ich könnte es mit einem Interface offensichtlicher machen.

Grüssli

[Firefighter]

Na klar, abwickeln.

Ja du kennst meine Meinung zur Compile-Time Faends mit dem Interface schoener, spart dir das extra beschreiben in der Doku.

[Dravere]

Firefighter schrieb:

Na klar, abwickeln.

Firefighter als Namen. Verwendet abfackeln statt abwickeln. Der nächste Feuerteufel-Feuerwehrmann?

Grüssli

PS: Ist mein Thread, ich darf Off-Topic sein :p

[Firefighter]

Dravere schrieb:

Firefighter schrieb:

Na klar, abwickeln.

Firefighter als Namen. Verwendet abfackeln statt abwickeln. Der nächste Feuerteufel-Feuerwehrmann?

Grüssli

PS: Ist mein Thread, ich darf Off-Topic sein :p

LOOOL du hast mich erwischt :D:D