L'uso del prefisso set / get è scoraggiato per i metodi se in realtà non mutano / accedono ai campi

Question

L'uso del prefisso set / get è scoraggiato per i metodi se in realtà non mutano / accedono ai campi

#1 da (8 voti)
#2 da (0 voti)

2

Questo potrebbe essere un capriccio dell'IDE che sto utilizzando, Android Studio, o potrebbe essere qualcosa di più sfumato che non capisco.

Ho un metodo setCustomFont che appare come una proprietà nella vista Struttura nel mio IDE. Sembra che AS stia prendendo questa decisione per classificarla come una proprietà basata sulla sua firma e sul prefisso set / get del nome del metodo. Il campo che pensa che sto mutando è customFont ma questo non esiste.

Ho cambiato il nome del metodo in applyCustomFont e ora la vista Structure in AS riflette qualcosa di più vicino alla verità nella mia classe.

Mi chiedevo se questo è di progettazione? Dovrei provare a stare lontano da set / get a meno che non disponga di un campo associato?

Modifica: mi sto anche interrogando sui nomi dei metodi sensibili, indipendentemente dal fatto che l'IDE abbia una vista Struttura .

refactoring java

posta piratemurray 30.06.2015 - 09:30

fonte

2 risposte

Leggi altre domande sui tag refactoring java

Come faccio a mostrare "crea" in un diagramma di classe UML? Autenticazione utente / password restful

score 8 · Answer 1

Questa non è una stranezza del tuo IDE - fa parte della convenzione Java Beans . Ci sono molti altri strumenti e librerie Java (ORM, serializzatori, lettori di configurazione, ecc.) Che si basano su queste convenzioni e non funzionano (o funzionano male) se disobbedite a loro.

Detto questo - i getter non dovrebbero sempre essere limitati ai campi fisici. Se hai una classe Circle con un campo radius , oltre al metodo getRadius() puoi anche avere un campo getArea() che calcola l'area dal raggio. Finché è possibile calcolare il risultato in modo rapido, privo di effetti collaterali, non vi è alcun problema con i getter che non sono mappati direttamente ai campi membri. Certo, significa che il tuo IDE ti mostrerà l'area oltre al raggio - e questo non dovrebbe essere un problema.

I setter sono una storia diversa, perché alcuni strumenti / librerie potrebbero usare la riflessione per invocare tutti i setter, che potrebbero alterare lo stato dell'oggetto in modi imprevisti. Ad esempio, nella tua classe un serializzatore potrebbe chiamare getCustomFont() , ricevere null (perché non c'è un font personalizzato), serializzarlo e quando lo leggerà chiamerà setCustomFont(null) e sostituirà il carattere non personalizzato.

score 0 · Answer 2

Data la popolarità di diversi tipi di framework che si basano sulla convenzione Java Beans, penso che dovremmo evitare il prefisso dei metodi con get / set se non rappresentano le proprietà dell'oggetto.

In alcune occasioni mi è capitato di aggiungere involontariamente un attributo inutile in una risposta JSON di un servizio, solo perché ho aggiunto un nuovo metodo helper get all'oggetto serializzato. A volte è solo un'informazione extra inutile, ma a volte causa NullPointerExceptions o simili.

Piuttosto, preferisco usare altri prefissi equivalenti, quindi invece di:

circle.getArea();

Avrei:

circle.calcArea();

In questo modo, inoltre, indico più esplicitamente che alcuni calcoli vengono eseguiti nel metodo, piuttosto che solo restituire un valore memorizzato.