Campi vs argomenti del metodo [chiuso]

Poiché il solo metodo esternamente visibile del tuo esempio è updateTable , penso che sia corretto utilizzare i campi invece dei parametri del metodo.

Se questo fa parte di una classe più generica (ad esempio TableTools ), sposterei i metodi di supporto che hanno bisogno dello stato in una classe interna nascosta.

Esempio di pseudo-codice:

class TableTools {
    ...
    public void updateTable(currentTable, newTable) {
        TableUpdater u = new TableUpdater(schemaModifier, currentTable, newTable);
        u.removeRemovedFields();
        u.addAddedFields();
     }

     private class TableUpdater { ... }
}

In tal modo, si evitano i campi utilizzati da un solo metodo pubblico. Inoltre, il codice è sicuro per i thread, nel senso che ogni chiamata a updateTable utilizza la propria copia di TableUpdater e, quindi, delle variabili di istanza di TableUpdater.

L'utilizzo dei campi coopone la possibilità di disporre del multithreading disponibile per i metodi che utilizzano tali campi.

L'utilizzo di campi di questo tipo è leggermente migliore rispetto all'utilizzo di globals dal punto di vista della riusabilità e della manutenibilità, il punto chiave è che le configurazioni complesse richiedono una documentazione attenta e aggiornata su quali metodi utilizzare e / o clobber quali campi; qualcosa che non devi fare quando usi gli argomenti.

In parole semplici:

I metodi
• dovrebbero avere il minor numero possibile di argomenti (Martin's Clean Code)
• una delle caratteristiche degli oggetti è di quanto possono (e dovrebbero) avere uno stato
• metodi non statici che non operano sullo stato dell'oggetto, cioè ricevono tutto come parametri, non sono coesivi
• i metodi non coesi potrebbero anche essere resi statici e raggruppati in una classe di utilità

Ancora una volta, a mio modesto parere, i metodi non coesivi appartengono a una classe di utilità e non a una classe con un nome di dominio.

Non utilizzare i campi nel caso corrente! Due "thread" che utilizzano l'oggetto nello stesso momento si confonderanno l'un l'altro. Non devono essere fili veri e separati (quindi le virgolette). Se imposti l'oggetto per una tabella, chiama un metodo che lo utilizza per un'altra tabella, quindi prova a utilizzare la configurazione originale, hai un problema. Segui i parametri per il momento.

Quello che vuoi fare qui è creare una nuova classe di aggiornamento che viene utilizzata in un solo caso. La classe originale potrebbe avere un metodo per creare un'istanza ogni volta che è necessario. La nuova classe avrebbe campi. Hai il meglio di entrambi i mondi. A volte è più semplice attenersi ai parametri, ma nel tuo esempio stai già arrivando dove una classe separata sarebbe migliore.

Penso che la scelta dovrebbe essere secondo la situazione reale, come la vedi tu. Se un elemento appartiene a un'istanza, dovrebbe essere visto come il suo campo. Se l'elemento è esterno all'istanza, deve essere passato come parametro del metodo.

In questo caso dovremmo essere guidati non dall'efficacia (comunque la differenza è insignificante), o (God save!) dalla facilità di battitura, ma dalla comprensibilità e dalla naturalezza del codice.

Secondo me se stai scrivendo il codice che fa qualcosa a qualcosa allora dovrebbe prendere dei parametri che definiscono le cose a cui dovrebbero fare e il suo nome dovrebbe definire il più possibile ciò che fa esso.

Se stai scrivendo il codice che impacchetta un'azione da eseguire su qualcosa , allora dovresti racchiudere le cose su cui dovrebbe essere eseguito in un oggetto e passarle alla tua cosa che fa qualcosa .

Questa azione diventa quindi una sorta di meta-descrizione delle chiamate ai metodi del primo che puoi poi eseguire in un secondo momento accodandolo o addirittura decidere di non farlo affatto per qualche ragione.

Quindi la tua domanda si traduce in è una azione o una funzione ? Un'azione potrebbe essere posticipata o annullata e pertanto dovrebbe incapsulare ciò su cui agisce. Una funzione avviene immediatamente, quindi non è più necessario conservare i suoi parametri.

Puoi annullare e azione ma non una funzione .