I nomi dei metodi getX e setX devono essere usati solo per i campi e non hanno altri effetti? [duplicare]

1

Dovrei evitare di usare getX() e setX() come nomi per metodi che non sono getter o setter "tradizionali"? (Definiamo tradizionale in quanto solo ottiene / imposta il campo e non ha altri effetti.) Suppongo che la domanda sia: un metodo chiamato così implica che è un campo dell'oggetto? Inoltre, è una cattiva pratica fare altre cose in loro?

class Foo {
    private Object bar;
    private Object bazz;

    // "traditional"
    public Object getBar() {
        return bar;
    }

    // bad practice?
    public Object getBazz() {
        doSomeOtherThing();
        return bazz;
    }

    // not a field
    public Object getJazz() {
        return makeSomeJazz();
    }

    // ...
}

Se getX() non è appropriato se non è un campo, che cos'è? (Probabilmente troppo ampio, mi rendo conto.) Ovviamente qualcosa come makeJazz() è probabilmente meglio di getJazz() se getJazz() è considerato negativo qui.

Suppongo che un'altra domanda sia davvero importante? Mi piace l'idea del "codice di auto-documentazione", ma forse mi preoccupo troppo di qualcosa di secondario.

    
posta Captain Man 30.04.2015 - 22:29
fonte

2 risposte

5

Diciamo che stai scrivendo un controllo della GUI e vuoi ridimensionarlo. Intuitivamente, dovresti avere un metodo setHeight e un metodo setWidth per le dimensioni. Questi dovrebbero impostare un valore sul controllo, ma se non causano anche il ricalcolo e il ridisegno del controllo, stai violando il diavolo da POLS, perché ci si aspetta che l'utente cambi le dimensioni del controllo in < em> modifica visibilmente le dimensioni del controllo . (Per non parlare del lasciare il controllo in uno stato incoerente, perché il valore del campo di supporto non corrisponde a quello mostrato sullo schermo.)

Invece di "impostare un valore e non avere altri effetti", la tua regola empirica dovrebbe essere "fare ciò che è necessario per portare l'oggetto in uno stato pienamente coerente, ma niente di più". A volte questo richiede solo l'impostazione di un valore. Altre volte, ci vorrà molto più lavoro.

    
risposta data 30.04.2015 - 23:13
fonte
2

Richiedere che i metodi getX corrispondano sempre a un campo interrompe l'incapsulamento .

Che il campo esista è un'informazione privata della classe, qualcosa su cui nessun'altra classe dovrebbe fare affidamento. Forse vorresti passare a una diversa implementazione un giorno. D'altra parte, il metodo getX è un'interfaccia pubblica. Se implicasse l'esistenza di un campo, dovrebbe essere rimosso se il campo fosse?

Diciamo che il nome completo di una persona ha sempre il formato "Nome Cognome" (ovviamente non lo sono, ma questo è un esempio). Puoi memorizzarlo con due campi, firstname e lastname , o con un campo name . Entrambe queste implementazioni consentono alle funzioni get_first_name , get_last_name e get_full_name di esistere. Va bene.

Un metodo getX dovrebbe comportarsi come se fosse solo una ricerca sul campo: dovrebbe essere veloce , dovrebbe essere costante (se il l'oggetto non è cambiato nel frattempo), dovrebbe avere nessun effetto collaterale non necessario e, se esiste un metodo setX, dovrebbe accettare qualsiasi valore restituito da getX e comportarsi come un metodo setX.

    
risposta data 01.05.2015 - 09:24
fonte

Leggi altre domande sui tag