Devo aggiungere parametri ai metodi di istanza che usano quei campi di istanza come parametri?

IMO, "rendere il mio metodo più" generico "e non affidabile sulla classe" non è un buon obiettivo, dal momento che promuove classi con bassa coesione .

Se il tuo metodo è abbastanza generico da servire anche per altre classi, allora estrailo dalla classe e spostalo in una classe "libreria di funzioni". (Ma fai attenzione al funzionale decomposizione antipattern ).

Ogni interfaccia che offri a clienti esterni ti dà delle restrizioni. Ad esempio, se hai un metodo

    public double computeMean(double[] values) {
    ...
    }

Ti stai promettendo di accettare double[] di matrici, ma se consegnassi il codice ai clienti e realizzi improvvisamente che ArrayList<Double> sarebbe meglio? E forse non sai se ci sono clienti che chiamano il tuo metodo, quindi non puoi semplicemente cambiarlo in ArrayList.

Se è pubblico e values è già noto alla classe, non hai bisogno dei parametri. Questo ti dà la libertà di cambiare da double[] a quello che vuoi, senza cambiare la tua interfaccia.

Se si tratta di un metodo privato, non hai bisogno dei parametri, sarebbero codice di codice perché già conosci i valori come hai detto.

Se vuoi una funzione veramente generica che non dipenda affatto dalla classe (il che significa che non c'è uno stato da tenere traccia di) puoi creare un metodo static che ottiene tutte le informazioni di cui ha bisogno dai parametri, se non tieni alcun stato nella tua classe in assoluto non hai nemmeno bisogno di un'istanza di questa classe. Come in Java Collections.sort (...).

Quindi dipende dai tuoi clienti se dovresti aggiungere i parametri.

Bene, a meno che non sia necessario interfacciarsi con il mondo esterno, non è utile aggiungere parametri, né se in vista di averne bisogno in seguito.

Se dovessi realizzare in un dato momento la necessità di fornire questo metodo con i parametri, allora potresti sovraccaricare questo metodo in quel momento, accettando i parametri nella nuova firma e gestendolo in questo modo.

In generale, tendo a considerare un buon approccio al design che lascia fuori dalla portata eventuali modifiche di seconda generazione, se le mie specifiche sono ben definite.

È meglio mantenere il design il più minimale possibile, ma aprirlo a eventuali modifiche successive.

Questo significa che, data una situazione come la tua, non è utile affidarsi immediatamente all'evoluzione del programma; attenersi invece alle specifiche effettive, progettando con un occhio a ciò che è ragionevole aspettarsi.

Breve anwer: se il metodo di istanza ha accesso alle variabili istanze, non è necessario passare quegli stessi valori dei parametri.

Se vuoi creare un metodo di classe (statico), allora tale metodo non avrà accesso a nessuno stato, quindi devi passare i valori come parametri.

Pensaci in questo modo. Se le variabili di istanza sono più correlate alla classe nel suo complesso, lasciarle nella classe. Se non sono correlati alla classe ma molto più ad un singolo metodo, rendili parametri.

Se pensi in questo modo, avrai anche una coesione più alta, che uno dei concetti di OO.

Se l'input del metodo deve essere nei campi di istanza o nei parametri dipende da che metodo . Dipende dalla semantica del metodo, dalla relazione del metodo con la classe e dalla sua semantica e dallo scopo dei campi all'interno della classe. Non hai specificato nessuno di questi, quindi la risposta potrebbe essere qualsiasi cosa.

In generale, se ha senso per il metodo fare tutto il suo lavoro dai parametri invece dei campi di istanza, allora il mio primo istinto sarebbe chiedersi perché il metodo sia anche in quella classe. Forse dovrebbe essere un metodo di utilità statico in alcune classi helper statiche.

Diversamente, se pensi che non ci siano dubbi sul fatto che il metodo dovrebbe essere chiaramente un metodo di istanza in quella classe, allora dovrebbe sembrare altrettanto inequivocabile che usi i campi di istanza della classe - sembra impossibile farlo qualsiasi altro modo. Dal momento che stai mettendo in discussione la questione, dovresti mettere in discussione la premessa.