Perché Java non implementa un modo migliore per gestire getter e setter? [chiuso]

0

Getter e setter sono ovunque in Java, ma sono gestiti in modo orribilmente obsoleto.

In parole semplici: perché una nuova versione di Java non consente una sintassi più semplice per gestirla? Anche se questa sintassi viene convertita in quella precedente dal compilatore per la compatibilità, almeno sarebbe utile lasciare che le persone scrivano il codice senza mettere i getter di boilerplate ovunque.

Ad esempio anziché:

private String id;

public String getId() {
    return id;
}

Potremmo semplicemente avere:

public readonly String id;

E poi, nel codice "client", invece di dover chiamare getId ovunque, il compilatore potrebbe rilevare se stai leggendo l'id della variabile e lo abbini automaticamente alla compilazione da una chiamata getId .

Esempio:

String userId = user.getId();

diventa:

String userId = user.id: // Compiler automatically manages the call to getId

Questo post non è qui per ranting, sono solo curioso di sapere se c'è un motivo per non farlo, perché sembra che Java possa davvero usare un aggiornamento su quel punto.

    
posta Malharhak 24.10.2015 - 19:37
fonte

2 risposte

4

Ci sono molti motivi per cui una particolare caratteristica linguistica in una lingua potrebbe non essere implementata.

In Java, l'associazione dei dati in Java Beans si basa sulla disposizione tradizionale dei metodi getter e setter, quindi non funzionerebbe con proprietà di prima classe a meno che non si riscrisse il raccoglitore. Perché devi ancora supportare la vecchia maniera, ora hai due modi diversi di fare la stessa cosa.

L'aggiunta di funzionalità linguistiche è costosa, e più la lingua è diffusa e popolare, più è costoso aggiungere la funzione. Ogni caratteristica linguistica che aggiungi deve giustificare la spesa; cioè, deve aggiungere più valore del tempo e degli sforzi richiesti per implementarlo. Ogni aggiunta di funzionalità linguistiche ha un costo opportunità; le risorse di tempo, denaro e programmatore non sono illimitate, quindi implementare una funzione a volte richiede di rinunciare a un'altra.

Eric Lippert descrive il processo meglio di chiunque altro Dice che

Just being a good feature is not enough. Features have to be so compelling that they are worth the enormous dollar costs of designing, implementing, testing, documenting and shipping the feature. They have to be worth the cost of complicating the language and making it more difficult to design other features in the future.

Un buon esempio di questo processo è proprietà dell'estensione in C #. Le proprietà di estensione sembrano un'aggiunta naturale a C #. Ma non erano essenziali come lo erano i Metodi di estensione. Come spiega Eric :

It was of course immediately obvious that the natural companion to extension methods is extension properties. It's less obvious, for some reason, that extension events, extension operators, extension constructors (also known as "the factory pattern"), and so on, are also natural companions. But we didn't even consider designing extension properties for C# 3; we knew that they were not necessary and would add risk to an already-risky schedule for no compelling gain.

Quindi non entrarono nel C # 3, che sarebbe stato il posto naturale dove metterli. Ora probabilmente non li otterremo mai, perché non sono davvero abbastanza convincenti come funzionalità autonoma per giustificare la spesa.

Ulteriori letture
Quanti dipendenti Microsoft impiegano per avvitare una lampadina?

    
risposta data 24.10.2015 - 20:33
fonte
3

Java è generalmente leggero sullo zucchero sintattico. Le uniche cose che ti vengono in mente sono String concatenazione con + e enhanced for loops. Sembra che i designer Java preferiscano aggiungere solo la sintassi per una semantica veramente nuova.

Tuttavia, le uniche persone che possono sicuramente rispondere a questa domanda sono i progettisti di Java.

Un consiglio: prova a scrivere una JSR per la tua modifica proposta e ad implementarla in uno dei compilatori Java open source (ad esempio OpenJDK javac , Eclipse ecj , ecc.). O ti imbatterai in problemi (ad esempio, un'ambiguità nella grammatica, un'ambiguità nella semantica dei campi rispetto ai metodi, l'infondatezza delle regole di risoluzione del sovraccarico, qualunque cosa ...), nel qual caso conosci la risposta alla tua domanda, o tu non incorrere in problemi, nel qual caso puoi proporre la tua modifica al JCP e forse verrà accettato.

Ho già la sensazione che ci saranno delle ambiguità nella risoluzione dei campi rispetto ai metodi, e sono curioso di sapere come gestirli.

    
risposta data 24.10.2015 - 20:02
fonte

Leggi altre domande sui tag