Utilizzo dello stesso nome per i metodi setter e getter per una variabile membro booleana

L'uso di isFancy per un setter non è certamente una convenzione standard e può quindi confondere i lettori del codice. Tuttavia, l'idea di utilizzare un'interfaccia fluente è buona. Se dovessi scegliere un nome da utilizzare nel tuo secondo esempio, userei semplicemente fancy() . Questo è un nome che puoi usare sia per il setter che per il getter senza confondere nessuno, ed è più corto dei nomi con prefissi set / get. Nota, tuttavia, che alcuni IDE e altri strumenti potrebbero non funzionare anche se il tuo getter / setter non ha i prefissi nel loro nome.

Ancora un'altra cosa che mi piace fare è rendere immutabili i miei oggetti di dati. Alcune lingue (ad esempio Kotlin e Scala) rendono ancora più semplice l'utilizzo di classi di dati immutabili, ma questo stile di programmazione funziona anche con Java. Semplifica la programmazione funzionale e consente di evitare alcuni tipi di errori, in particolare nel codice parallelo. È possibile combinare l'immutabilità con il secondo approccio utilizzando una classe di builder separata. Questo aggiunge alcune linee di codice, ma (supponendo che ci sia più di un solo campo), l'overhead non è poi così male e in seguito l'oggetto risultante è abbastanza piacevole da usare:

public final class MyClass {
    private final boolean fancy;

    private MyClass(boolean fancy) {
        this.fancy = fancy;
    }

    public static Builder builder() {
        return new Builder();
    }

    public boolean fancy() { return fancy; }

    public static class Builder {
        private boolean fancy = false;

        public fancy(boolean fancy) { this.fancy = fancy; }

        public MyClass build() { return new MyClass(fancy); }
    }
}

Un ulteriore vantaggio è che puoi impostare dei valori di default ragionevoli nel tuo costruttore. Puoi anche passare il builder tra i metodi fino a quando l'oggetto viene costruito, quindi per esempio il valore di fantasia può essere impostato in diversi posti se è necessario, ma una volta creato l'oggetto finale tramite build() , è immutabile e quindi thread-safe (e sai che a questo punto non può essere modificato in alcun modo non intenzionale).

Quindi il modo più breve per costruire il tuo oggetto è:

builder().fancy(true).build();

ma puoi anche dividerlo in più chiamate:

Builder builder = builder();
builder.fancy(result_of_some_calculation)
// do other stuff
if (something) {
    builder.fancy(result_of_another_calculation)
}
callSomeMethod(builder.build())

Ovviamente, maggiore è il numero di campi che hai, maggiore sarà l'utilizzo che otterrai dal modello di builder con classe di dati immutabili.

Non direi che nulla è intrinsecamente sbagliato in questo. Ma non è il tipo di metodo che cercherò se stavo cercando un setter. Con quel nome potrei aspettarmi di essere in grado di recuperare se l'oggetto è di fantasia, con qualche tipo di switch booleano (che non suggerirei neanche, ma è fuori tema)

Suppongo che dipenda da chi altro sta leggendo il codice e se davvero vuoi prendere questa abitudine. Se scrivi sempre codice per te stesso, puoi certamente scegliere ciò che ti fa sentire bene.

(Potresti sempre scrivere Scala dove nulla di ciò è importante, o qualsiasi altra lingua sulla JVM con get / setter nativi o qualche altro meccanismo)