Meglio avere 2 metodi con un significato chiaro o solo 1 metodo a doppio uso?

Per semplificare l'interfaccia, è meglio non avere il getBalance()metodo? Passare 0al charge(float c);darà lo stesso risultato:

public class Client {
    private float bal;
    float getBalance() { return bal; }
    float charge(float c) {
        bal -= c;
        return bal;
    }
}

Forse prendi nota javadoc? Oppure lascialo all'utente della classe per capire come ottenere l'equilibrio?

Sembra che tu suggerisca che la complessità di un'interfaccia sia misurata dal numero di elementi che possiede (metodi, in questo caso). Molti sosterrebbero che dover ricordare che il chargemetodo può essere usato per restituire l'equilibrio di un Clientaggiunge molta più complessità che avere l'elemento extra del getBalancemetodo. Rendere le cose più esplicite è molto più semplice, specialmente al punto in cui non lascia alcuna ambiguità, indipendentemente dal numero più elevato di elementi nell'interfaccia.

Inoltre, chiamare charge(0)viola il principio del minimo stupore , noto anche come metrica WTF al minuto (da Clean Code, immagine sotto), rendendo difficile per i nuovi membri del team (o quelli attuali, dopo un po 'di distanza dal codice) fino a capiscono che la chiamata viene effettivamente utilizzata per ottenere il saldo. Pensa a come reagirebbero gli altri lettori:

Inoltre, la firma del chargemetodo è in contrasto con le linee guida per la separazione di una sola cosa e comando-query , perché fa sì che l'oggetto cambi il suo stato restituendo al contempo un nuovo valore.

Tutto sommato, credo che l'interfaccia più semplice in questo caso sarebbe:

public class Client {
  private float bal;
  float getBalance() { return bal; }
  void charge(float c) { bal -= c; }
}

IMO, la sostituzione getBalance()con charge(0)tutta l'applicazione non è una semplificazione. Sì, ha meno righe, ma offusca il significato del charge()metodo, che potrebbe potenzialmente causare mal di testa lungo la linea quando tu o qualcun altro ha bisogno di rivisitare questo codice.

Sebbene possano dare lo stesso risultato, ottenere il saldo di un conto non equivale a un addebito pari a zero, quindi sarebbe probabilmente meglio separare le tue preoccupazioni. Ad esempio, se hai mai avuto bisogno di modificare charge()per accedere ogni volta che si verifica una transazione del conto, ora hai un problema e dovresti comunque separare la funzionalità.

È importante ricordare che il codice dovrebbe essere auto-documentato. Quando chiamo charge(x), mi aspetto xdi essere addebitato. Le informazioni sull'equilibrio sono secondarie. Inoltre, potrei non sapere come charge()viene implementato quando lo chiamo e sicuramente non saprò come verrà implementato domani. Ad esempio, considera questo potenziale aggiornamento futuro per charge():

float charge(float c) {
    lockDownUserAccountUntilChargeClears();
    bal -= c;
    Unlock();
    return bal;
}

Improvvisamente usare charge()per ottenere l'equilibrio non sembra così buono.

Usare charge(0);per ottenere il saldo è una cattiva idea: un giorno qualcuno potrebbe aggiungere un po 'di codice lì per registrare gli addebiti effettuati senza rendersi conto dell'altro uso della funzione, e quindi ogni volta che qualcuno ottiene il saldo verrà registrato come addebito. (Ci sono modi per aggirare questo come un'istruzione condizionale che dice qualcosa del tipo:

if (c > 0) {
    // make and log charge
}
return bal;

ma questi si basano sul programmatore che sa implementarli, cosa che non farà se non è immediatamente ovvio che sono necessari.

In breve: non fare affidamento né sui tuoi utenti né sui successori dei programmatori che charge(0);si rendono conto che è il modo corretto di ottenere l'equilibrio, perché a meno che non ci sia documentazione sulla loro garanzia di non perdere, allora francamente sembra il modo più spaventoso di ottenere l'equilibrio possibile.

So che ci sono molte risposte, ma un altro motivo charge(0)è che un semplice errore charge(9)causerà la diminuzione del saldo del cliente ogni volta che si desidera ottenere il proprio saldo. Se hai un buon test unitario potresti essere in grado di mitigare quel rischio, ma se non riesci ad essere diligente in ogni chiamata, chargepotresti avere questo contrattempo.

Vorrei menzionare un caso particolare in cui avrebbe senso avere meno metodi, più multiuso, se c'è molto polimorfismo, cioè molte implementazioni di questa interfaccia ; specialmente se quelle implementazioni sono in codice sviluppato separatamente che non può essere aggiornato in sincronia (l'interfaccia è definita da una libreria).

In tal caso, semplificare il lavoro di scrittura di ogni implementazione è molto più prezioso della chiarezza dell'uso di essa, poiché il primo evita bug di violazione del contratto (i due metodi sono incoerenti tra loro), mentre il secondo danneggia solo la leggibilità, che può essere recuperato da una funzione di supporto o da un metodo superclasse che definisce getBalancein termini di charge.

(Questo è un modello di progettazione, per il quale non ricordo un nome specifico: definire una complessa interfaccia intuitiva per il chiamante in termini di una minima intuitiva per gli implementatori. In Mac OS classico l'interfaccia minima per le operazioni di disegno era chiamata "collo di bottiglia" ma questo non sembra essere un termine popolare.)

Se questo non è il caso (ci sono poche implementazioni o esattamente una), allora ha senso separare i metodi per chiarezza e consentire la semplice aggiunta di comportamenti rilevanti per addebiti diversi da zero charge().