Warum haben OOP-Sprachen keinen Zugriffsmodifizierer, der nur gelesen werden kann?

Question

Jedes Mal, wenn ich triviale Getter schreibe (Funktionen holen, die nur den Wert des Members zurückgeben), frage ich mich, warum Sprachen nicht einfach einen 'Nur lesen'-Zugriffsmodifikator haben, der es erlaubt, den Wert der Member des Objekts zu lesen erlaubt es nicht, sie genau wie const in C++ zu setzen.

Die privaten, geschützten, öffentlichen Zugriffsmodifikatoren bieten entweder vollen (Lese-/Schreib-) Zugriff oder keinen Zugriff.

Einen Getter zu schreiben und jedes Mal aufzurufen, ist langsam, weil das Funktionsaufrufen langsamer ist als nur auf ein Mitglied zuzugreifen. Ein guter Optimierer kann diese Getter-Aufrufe optimieren, aber das ist "Magie". Und ich denke nicht, dass es eine gute Idee ist zu lernen, wie ein Optimierer eines bestimmten Compilers funktioniert, und Code zu schreiben, um ihn zu nutzen.

Warum also müssen wir in der Praxis Accessoren schreiben, nur Schnittstellen lesen, wenn nur ein neuer Zugriffsmodifikator das tun würde?

PS1: Bitte sagen Sie nicht Dinge wie "Es würde die Kapselung brechen". Eine öffentliche foo.getX() und eine öffentliche, aber nur lesen foo.x würde das gleiche tun.

EDIT: Ich habe meinen Beitrag nicht klar geschrieben. Es tut uns leid. Ich meine, Sie können den Wert des Mitglieds außerhalb lesen, aber Sie können es nicht einstellen. Sie können den Wert nur innerhalb des Klassenbereichs festlegen.

Answer 1

Sie verallgemeinern falsch von einer oder mehreren OOP-Sprache (n), die Sie kennen, in OOP-Sprachen im Allgemeinen. Einige Beispiele für Sprachen, die implementieren Nur-Lese-Attribute:

• C# (Danke, Darin und Tonio)
• Delphi (= Object Pascal)
• Rubin
• Scala
• Objective-C (Dank , Rano)
• ... mehr?

Persönlich bin ich genervt, dass Java das nicht hat (noch?). Wenn man das Feature in anderen Sprachen gesehen hat, scheint das Schreiben von Texten in Java ermüdend zu sein.

Answer 2

Nun some OOP languages do have solche Modifikator.

Answer 3

C# -Eigenschaften ermöglichen das einfache Definieren von schreibgeschützten Eigenschaften. Siehe hierzu article.

Answer 4

C# hat readonly, Java und einige andere haben final. Sie können diese verwenden, um Ihre Membervariablen schreibgeschützt zu machen.

In C# können Sie einfach einen Getter für Ihre Eigenschaft angeben, sodass er nur gelesen, nicht geändert werden kann.

private int _foo; 

public int Foo 
{ 
    get { return _foo; } 
} 

Answer 5

Eigentlich sind sie nicht gleich. Public foo.getX() würde weiterhin zulassen, dass der interne Klassencode in die Variable schreibt. Eine schreibgeschützte foo.x wäre auch für den internen Klassencode schreibgeschützt.

Und es gibt einige Sprachen, die solche Modifikator haben.

Answer 6

In C# können Sie eine automatische Eigenschaft mit unterschiedlichen Zugriffs-Qualifikation auf dem Set definieren und erhalten:

public int Foo { get; private set; } 

Auf diese Weise kann die Klasse Umsetzung seiner Herzenslust mit der Eigenschaft herumzubasteln, während Client-Code kann lies es nur.

Answer 7

Nicht Objective-C 2.0 Eigenschaft schreibgeschützt zu erwähnen Accessoren http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocProperties.html

Answer 8

In Delphi:

strict private 
    FAnswer: integer; 
public 
    property Answer: integer read FAnswer; 

Deklariert eine schreibgeschützte Eigenschaft Antwort, die private Bereich FAnswer zugreift.

Answer 9

Die Frage läuft im Wesentlichen darauf hinaus: warum hat nicht jede Sprache eine konstante Eigenschaft wie C++? Dies ist

, warum es nicht in C#:

Anders Hejlsberg: Ja. In Bezug auf const, es ist interessant, weil wir diese Beschwerde die ganze Zeit zu hören: "Warum hast du const?" Implizit in der Frage ist, "Warum haben Sie const, die durch die Laufzeit erzwungen wird?" Das ist wirklich was Leute fragen, obwohl sie nicht kommen und es so sagen.

Der Grund, dass Konst in C++ funktioniert, ist , weil Sie es wegwerfen können. Wenn du es nicht wegwerfen könntest, dann würde deine Welt lutschen. Wenn Sie eine Methode deklarieren, die eine Const Bla nimmt, könnten Sie es eine nicht-const Bla übergeben. Aber wenn es die anders herum ist, können Sie nicht. Wenn Sie deklarieren eine Methode, die eine nicht-const Bla nimmt, können Sie es nicht const Bla übergeben. Jetzt bist du festgefahren. So brauchen Sie allmählich eine const-Version von alles, was nicht const ist, und Sie am Ende mit einer Schattenwelt. In C++ gehen Sie mit davon weg, denn wie bei ist alles in C++ rein optional , ob Sie diese Prüfung wollen oder nicht. Sie können einfach die Konstanz weg whack, wenn Sie es nicht mögen.

See: http://www.artima.com/intv/choicesP.html

Also, der Grund wy const in C++ gewohnt ist, weil man es umgehen kann. Das ist sinnvoll für C++, das seine Wurzeln in C.

hat. Für verwaltete Sprachen wie Java und C# würden Benutzer erwarten, dass const genauso sicher wäre wie etwa der Garbage Collector. Das bedeutet auch, dass Sie nicht umgehen können, und es wird nicht nützlich sein, wenn Sie nicht umgehen können.