Warum hat Java keine automatischen Eigenschaften wie C#?

Question

C# verfügt über eine automatische Eigenschaften, die stark Ihren Code vereinfachen:

public string Name { get; set; } 
public string MiddleName { get; set; } 
public string LastName { get; set; } 

Während Java hat man so viel Code schreiben:

private String name; 
private String middleName; 
private String LastName; 

public String Name(){ 
    return this.name; 
} 

etc.. 

Gibt es einen bestimmten Grund, Java so etwas wie dieses nicht umgesetzt hat?

Answer 1

Es ist nicht so einfach, einer vorhandenen Programmiersprache neue Funktionen hinzuzufügen, insbesondere wenn Sie auf Abwärtskompatibilität achten. Sun war immer sehr vorsichtig beim Hinzufügen neuer Funktionen zu Java, weil sie absolut sicher sein wollten, dass jede neue Sprachfunktion die Millionen von Java-Programmen, die über die Jahre hinweg geschrieben wurden, nicht durchbrechen wird.

Also, es ist nicht nur eine Frage des Hinzufügens zu der Sprache; Sie müssen sehr genau überlegen und es ausprobieren, um herauszufinden, ob es subtile Rückwärtskompatibilitätsprobleme mit dem neuen Feature gibt, das Sie hinzufügen möchten.

Es gab Vorschläge zum Hinzufügen von Unterstützung für Eigenschaften in der einen oder anderen Form in Java, aber es sieht für Java 7 (die nächste kommende Version) aus, dies ist kein Feature, das in Betracht gezogen wird.

Vielleicht möchten Sie einen Blick auf Project Lombok werfen, die eine Art Erweiterung zu Java ist, mit Annotationen, um es zu ermöglichen, mehr prägnanten Code zu schreiben (es kann zum Beispiel automatisch Getter und Setter für Felder generieren) .

Answer 2

Ja, weil es es nicht hat. Wie das Sprichwort sagt, beginnen alle Features nicht implementiert.

Answer 3

.net kam nach Java, und eines seiner Ziele war die Interoperabilität mit COM. COM hatte Eigenschaften, wahrscheinlich eine la VB, also musste .net sie alle hinzufügen, um Sprachen interoperabel zu machen. (Das und sie waren eine ziemlich schlaue Idee.)

Java hatte solch eine Notwendigkeit nicht, und seine Erschaffer wollten wahrscheinlich nicht die Bedeutung von "=" verschmutzen oder Funktionsaufrufe wie Elementvariablen aussehen lassen. (Sie waren - oder waren zumindest irgendwann - daran interessiert, die Sprache so sauber wie möglich zu halten.) Ihr Ansatz war stattdessen die Java-Bean-Spezifikationen, die eine Namenskonvention für Getter und Setter vorgaben. IDEs, die die Spezifikation kennen, können mehr oder weniger die Ansicht des Getter und Setter als eine einzige "Eigenschaft" für Entwurfszwecke verfälschen.

Answer 4

Aus dem gleichen Grund hat die C# 2.0 oder niedriger das nicht. Es ist mehr oder syntaktischer Zucker, eher ein Sprachmerkmal. Es gibt so viele Funktionen wie diese, die jeder Sprache hinzugefügt werden können, aber keiner weiß, warum sie nicht die Sprache sind.

Answer 5

Automatische Eigenschaften basieren auf Eigenschaften.

Eigenschaften in C# sind ein Sprachfeature, in Java sind sie eine Konvention (Methoden, die mit get oder set beginnen, werden oft als Eigenschaften von Leuten betrachtet, die über den Code sprechen, aber für den Compiler nicht anders als foo oder bar).

.NET und die zugehörigen Sprachen, wo in vielerlei Hinsicht auf COM basiert (manchmal in Folge Anzug, manchmal in absichtlich nicht etwas in COM, das aus irgendeinem Grund oder anderen unpopulär war).

COM hat ein Konzept von Eigenschaften, die in VB durch Sprachfeatures unterstützt wurden (in C++ wurde es von Konventionen unterstützt).

Frühere Versionen von VB, insbesondere in Kontexten, in denen es grundlegenden programmatischen Zugriff auf Objektmodelle von anderswo lieferte, sollten die Objektmodelle vereinfachen, die den Benutzern zur Unterscheidung zwischen einem Feld und einer Methode zur Verfügung gestellt werden Sätze (vielleicht mit zusätzlicher Arbeit, vielleicht nicht) unwichtig (bedenken Sie, dass, während sie sich in einer wichtigen Weise von außen in .NET unterscheiden, der syntaktische Zugriff auf eine Eigenschaft und ein öffentliches Feld derselbe ist). Als VB und COM (und davor OLE) aufwuchsen, sind sie zusammen aufgewachsen.

Also, während C# eine C/C++ - Vererbung mit Java teilt, hat es auch eine Vererbung, die Java nicht teilt, was Eigenschaften wie eine gute Idee für C# 's Schöpfer, aber nicht für Java macht.

Edit: Zuerst sagte ich:

---

Ich persönlich denke, automatische Eigenschaften sind wirklich eine Abhilfe zu einem Fehler in Eigenschaften, anstatt ein Weg, um Ihren Code zu vereinfachen. Eigenschaften "sehen" wie öffentliche Felder syntaktisch aus, sind aber nicht vollständig (versuchen Sie es mit DataBinder.Eval, um ein Feld abzurufen). Wenn eine Eigenschaft sowohl vollständig öffentlich ist, als auch keine zusätzliche Funktionalität in Getter oder Setter hat (was bei automatischen Eigenschaften der Fall ist), würde ich lieber ein öffentliches Feld haben (Kapselung ist hier kein Argument, wie es vollständig öffentlich verfügbar macht- passiert das sowieso), aber die Unterschiede zwischen Feldern und Eigenschaften wirken dagegen.

---

Ich ziehe diese Aussage zurück. Wenn Felder genau wie Eigenschaften erstellt werden, müssten die Felder einfacher Plain-Old-Data-Strukturen wie Eigenschaften agieren, was eine Performance-Loose wäre. Konzeptuell möchte ich, dass sie einander ähnlicher sind, aber wann immer ich darüber nachdenke (und ich bin genervt davon geworden, "Oh, warte" wie hier, mehr als einmal), es ist besser so wie es ist.