Perché Java non ha proprietà automatiche come C#?

Question

C# ha proprietà automatiche che semplificano notevolmente il tuo codice:

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

Mentre Java ha scritto questo molto codice:

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

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

etc.. 

C'è un motivo particolare Java non ha attuato qualcosa di simile?

Answer 1

Non è così facile aggiungere nuove funzionalità a un linguaggio di programmazione esistente, soprattutto se si è interessati alla retrocompatibilità. Sun è sempre stata estremamente attenta nell'aggiungere nuove funzionalità a Java, perché voleva essere assolutamente sicuro che qualsiasi nuova funzionalità linguistica non avrebbe infranto i milioni di programmi Java che sono stati scritti nel corso degli anni.

Quindi, non è solo una questione di aggiungere questo al linguaggio; devi pensare con molta attenzione, e provarlo, per scoprire se non ci sono problemi di compatibilità con le versioni precedenti con qualsiasi nuova funzionalità tu voglia aggiungere.

Ci sono state proposte per aggiungere il supporto per le proprietà in una forma o in un'altra in Java, ma sembra per Java 7 (la prossima versione in arrivo) questa non è una funzionalità che viene considerata.

Si potrebbe dare un'occhiata a Project Lombok, che è una sorta di estensione a Java, utilizzando annotazioni, per rendere possibile scrivere codice più conciso (può, ad esempio, generare automaticamente getter e setter per i campi) .

Answer 2

Sì, perché non ce l'ha. Come si suol dire, tutte le funzionalità iniziano non implementate.

Answer 3

.net è arrivato dopo Java, e uno dei suoi obiettivi era quello di interoperare con COM. COM aveva proprietà, probabilmente a la VB, quindi. Tutti ma dovevano aggiungerle per rendere interoperabili le lingue. (Quello, ed erano un'idea piuttosto spigolosa.)

Java non aveva tale necessità, ei suoi creatori probabilmente non volevano inquinare il significato di "=" o rendere le chiamate di funzioni simili a variabili membro. (Sono - o almeno erano, a un certo punto - grandi nel mantenere la lingua il più pulita possibile). Il loro approccio era invece le specifiche del bean Java, che specificavano una convenzione di denominazione per getter e setter. Gli IDE che conoscono le specifiche possono fudire più o meno la vista del getter e setter come una singola "proprietà" per scopi di progettazione.

Answer 4

Per lo stesso motivo il C# 2.0 o inferiore non ha questo. È uno zucchero più o sintattico, piuttosto una funzionalità linguistica. Ci sono un sacco di funzionalità come questa che potrebbero essere aggiunte a qualsiasi lingua, ma non si sa perché non sono la lingua.

Answer 5

Le proprietà automatiche sono basate sulle proprietà.

Le proprietà in C# sono una funzionalità linguistica, in Java sono una convenzione (i metodi che iniziano con get o set sono spesso considerati proprietà da persone che parlano del codice, ma per il compilatore non è diverso da foo o bar).

.NET e le lingue associate, in molti casi basate su COM (a volte nel seguente seme, a volte in modo deliberato non fare qualcosa in COM che era per qualche motivo o altro impopolare).

COM ha un concetto di proprietà che in VB era supportato da funzionalità di linguaggio (in C++ era supportato da convenzioni).

Versioni precedenti di VB, soprattutto in contesti in cui era utilizzato per fornire accesso programmatico di base a modelli di oggetti forniti da altrove, finalizzati a semplificare i modelli di oggetti presentati agli utenti per fare la distinzione tra un campo e un metodo che ottiene o set (magari con lavoro aggiuntivo, forse no) non importante (si consideri che mentre differiscono in qualche modo importante dall'esterno in .NET, l'accesso sintattico a una proprietà e un campo pubblico è lo stesso). Quando VB e COM (e prima di quell'OLE) sono cresciuti, sono cresciuti insieme.

Dunque in tutto, mentre C# condivide l'ereditarietà di C/C++ con Java, ha anche un'eredità che Java non condivide, il che ha fatto apparire le proprietà come una buona idea per i creatori di C#, ma non per Java.

Edit: In un primo momento ho detto:

---

Personalmente, penso che le proprietà automatiche sono davvero una soluzione a un difetto nella proprietà, piuttosto che un modo per semplificare il codice. Le proprietà "sembrano" sintatticamente come i campi pubblici, ma non sono interamente (prova a utilizzare DataBinder.Eval per recuperare un campo). Se una proprietà fosse completamente pubblica e non avesse alcuna funzionalità aggiuntiva in getter o setter (come nel caso delle proprietà automatiche), preferirei semplicemente avere un campo pubblico (l'encapsulation non è argomento qui, poiché lo esponete completamente pubblicamente da- passa comunque), ma le differenze tra campi e proprietà funzionano contro questo.

---

ritiro questa dichiarazione. Rendere i campi esattamente come le proprietà richiederebbe che i campi di semplici strutture Plain-Old-Data agissero come proprietà, il che sarebbe una performance allentata. Concettualmente, mi piacerebbe che fossero più simili tra loro, ma ogni volta che ci penso (e sono passato dall'essere infastidito ad andare "oh aspetta" come qui più di una volta), è meglio così com'è.