Perché alcuni progetti hanno getter e setter per variabili di istanza pubbliche?

2

Stavo esaminando un progetto di framework per giochi open source scritto in Java. Ha diverse classi che:

  • Hanno variabili di istanza pubbliche.
  • avere getter / setter per tali variabili.

Generalmente, scrivo getter / setter quando voglio incapsulare un comportamento che si verifica quando una proprietà viene modificata.

Tuttavia, guardando il codice, si tratta letteralmente di qualcosa del genere:

public class Test {
    public int value;
    public void setValue(x) {
        value = x;
    }
    public void getValue() {
        return value;
    }
}

Poi ho pensato di controllare il resto del framework e vedere come modificano tale valore, il che potrebbe darmi un suggerimento sul perché hanno fatto quanto sopra.

Da quello che ho visto, lo fanno in questo modo:

object.value = 100;

Senza usare i getter / setter.

Quindi ora non sono sicuro di quale sia stato il punto di creare getter / setter.

Quindi, la mia domanda è, c'è una ragione per cui vorrei creare getter / setter per un valore pubblico, se tali getter / setter non implementano nemmeno alcun tipo di comportamento speciale?

    
posta Omega 02.01.2014 - 05:37
fonte

4 risposte

8

Sembra che gli autori della classe siano stati confusi o abbiano cambiato idea a metà strada scrivendola. Nella maggior parte dei casi, gli attributi pubblici sono una "cosa cattiva" e gli accessor pubblici sono la strada da percorrere: consentono alla classe di modificare l'implementazione e persino di rifiutare l'operazione. In breve, per proteggere il proprio stato interno.

    
risposta data 02.01.2014 - 05:44
fonte
1

In un certo numero di lingue, le classi possono esporre i campi, ma le interfacce non possono. In alcuni casi, può essere utile che una classe esponga le informazioni tramite il suo tipo di classe (nel qual caso i consumatori potrebbero utilizzare i campi) e tramite un'interfaccia (nel qual caso i consumatori devono utilizzare i metodi).

Ad esempio, un'interfaccia Location3d potrebbe definire metodi getX() , getY() e getZ() . Una classe Point3d potrebbe definire i campi X, Y, Z e implementare anche tale interfaccia. Altri oggetti che hanno posizioni, ma non memorizzano direttamente X, Y e Z, potrebbero implementare l'interfaccia per consentire ad altre entità di informarsi sulla loro posizione.

Continuando nell'esempio, una classe Monster in un gioco potrebbe esporre un EnemyLocation che trattiene un riferimento al mostro e implementa i metodi getX() etc. in modo che segnalino continuamente la posizione del nemico attuale del mostro . Se la EnemyLocation memorizza le coordinate direttamente, o anche se contiene un riferimento al Point3d del nemico corrente, le coordinate non vengono aggiornate quando un mostro trova un nuovo nemico da bersagliare. Se, tuttavia, i suoi metodi getX() etc. esaminano il mostro attaccato e leggono la posizione attuale del nemico presente di quel mostro, possono sempre riportare dati aggiornati.

    
risposta data 13.03.2014 - 19:26
fonte
0

Direi che i due motivi più probabili sono:

  1. Che i getter ei setter sono stati generati automaticamente dagli strumenti authours.
  2. La variabile era inizialmente impostata come un ambito più ristretto e qualcun altro l'ha cambiata.
risposta data 13.03.2014 - 22:42
fonte
0

Non sei sicuro del motivo per cui avresti un membro pubblico, a meno che non fosse statico, const, readonly, ecc.

Penso che le proprietà pubbliche dovrebbero essere sempre preferite ai membri pubblici; se è necessario apportare modifiche a un membro pubblico, o qualsiasi ragione, significherà che tutte le chiamate esistenti al di fuori della classe dovranno essere aggiornate. Le proprietà offrono un altro livello per cambiare le cose internamente senza (si spera) avere un impatto al di fuori della classe.

Supercat è anche un ottimo punto di riferimento per le interfacce.

    
risposta data 27.09.2014 - 04:40
fonte

Leggi altre domande sui tag