Const Korrektheit in C # mit reichen Typen

8

Ausgehend von einem C ++ - Hintergrund und dem Versuch, C # zu lernen, ist eine der frustrierendsten Sprachunterlassungen, die ich gefunden habe, eine Entsprechung zum const -Schlüsselwort.

Ich habe also versucht, ein Muster zu finden, mit dem ich in C # eine konstante Korrektheit erreichen kann.

Diese Antwort hat einen interessanten Vorschlag: Erstellen Sie eine schreibgeschützte Schnittstelle für alle Ihre Typen. Aber wie Matt Cruikshank in den Kommentaren darauf hingewiesen hat, wird dies problematisch, wenn Ihre Klasse Sammlungen oder andere reiche Typen hat. Vor allem, wenn Sie keine Kontrolle über den Typ haben und keine schreibgeschützte Schnittstelle implementieren können.

Gibt es Muster oder Lösungen, die mit reichen Typen und Sammlungen umgehen können, oder müssen wir in C # einfach Kopien erstellen? Ist es besser, die const-Korrektheit in C # überhaupt aufzugeben?

    
Eric 24.07.2012, 21:11
quelle

1 Antwort

7

Kannst du in C # unveränderbar werden? Sicher, wenn Sie dafür entwerfen. Sie können kreative Dinge mit Schnittstellen tun und so weiter, dass nur die get der Eigenschaften und keine der änderbaren Methoden verfügbar gemacht werden.

Denken Sie daran, dass es nichts gibt, das einen schlauen Benutzer davon abhält, ihn zurück auf den tatsächlichen Typ zu übertragen (natürlich könnte man auch von C ++ sprechen, Sie können const-ness wegwerfen).

%Vor%

Gleiches gilt für Sammlungen. Selbst wenn Sie eine ReadOnlyCollection zurückgeben (was Mutationsverhalten in der Sammlung selbst verhindert), sind die Daten in der Sammlung immer noch veränderbar (solange der Typ dies natürlich zulässt).

Ich fürchte, es gibt hier wirklich keine einfache Antwort. Es gibt kein "flip-a-switch" const, das Ihnen das gibt, was C ++ tut.

Es liegt wirklich an Ihnen, Sie können:

  • Entwerfen Sie Ihre Typen als unveränderlich und geben Sie Iteratoren (oder andere schreibgeschützte Sequenzen) anstelle von änderbaren Sammlungen zurück.
  • Gib jedes Mal neue Kopien zurück, so dass es kein Problem ist, wenn sie geändert werden.
  • Geben Sie nur die tatsächlichen Daten zurück und lassen Sie das Manipulationsverhalten als "undefiniert".
  • usw. ...

Letzteres ist, was Sammlungen wie Dictionary<TKey, TValue> tun. Es gibt nichts, das besagt, dass Sie den Schlüsseltyp nicht zu einem veränderlichen Typ machen können (aber wehe, wenn Sie das tun), und die MSDN ist ziemlich klar, dass wenn Sie den Schlüssel so ändern, dass sich der Hash-Code ändert, liegt er auf Ihrem eigenen Hals ...

Für meine eigene Arbeit tendiere ich dazu, es einfach zu halten, es sei denn, es besteht eine große Sorge, dass meine Klasse so verändert werden könnte, dass sie Nebenwirkungen verursacht. Wenn ich beispielsweise Web-Service-Ergebnisse in einem Cache speichere, gebe ich stattdessen eine Kopie des zwischengespeicherten Elements zurück, sodass der zwischengespeicherte Wert nicht unbeabsichtigt geändert wird, wenn ein Benutzer das Ergebnis ändert.

Also, kurz und lang ist, dass ich mir keine Gedanken über die Korrektheit von jedem -Typ machen würde, den Sie zurückgeben, das ist einfach viel zu viel. Ich würde mich nur um Dinge kümmern, die Sie zurückgeben, die, wenn sie geändert werden, einen Nebeneffekt für andere Benutzer erzeugen könnten.

    
James Michael Hare 24.07.2012, 21:28
quelle