Elenco dei parametri lunghi rispetto all'elenco delle variabili a stato lungo

Dipende se si sta programmando in un paradigma procedural o functional . Lo stato mutevole è richiesto per il primo e paralizzante per il dopo. Questo è mele e arance. Sono entrambi corretti nei loro bailiwicks!

È possibile applicare un singolo compito e altre tecniche funzionali a linguaggi procedurali imperativi, lo stato immutabile rende la programmazione concorrente più deterministica, ma rendere ogni oggetto immutabile in un linguaggio come Java o C ++ è quasi impossibile perché i loro modelli di memoria non supportano facilmente questo paradigma.

Se capisco bene la tua domanda, stai mettendo in discussione quali condizioni qualificano l'uso di un parametro o di una variabile di classe / membro / campo / etc? Suppongo che tu ti stia riferendo a un metodo e non a una funzione. Se si tratta specificamente di C ++, suggerisco di spostare la domanda allo stack overflow.

Un lungo elenco di parametri può essere un segno che potrebbe essere necessario rifattorizzare il metodo in un insieme di quelli più granulari. In generale, l'uso dei parametri renderà il codice più liberamente accoppiato. Non sono sicuro che questo sia vero per la maggior parte dei moderni linguaggi OO, ma la creazione di oggetti può essere costosa, specialmente se sono coinvolte molte variabili di classe; quindi, se le variabili di classe fossero oggetti e fossero referenziati frequentemente in un programma, allora potrebbero essere giustificati come variabili di classe.

Inoltre:

• Altri metodi potrebbero utilizzare le variabili di classe? Se sì, allora considera di andare con le variabili di classe.
• Il tuo metodo è pubblico? Se pubblico, usa i parametri.
• Il tuo elenco di parametri può essere opportunamente rappresentato come un hash / mappa / array / collezione / elenco / etc? Se è così, considera un'opzione.
• Il tuo metodo è statico? Se sì, usa i parametri.

No, le variabili di stato di per se non causano effetti collaterali.

Chiamare un metodo setter (su una struttura dati che è visibile altrove) è un effetto collaterale.

Puoi avere strutture dati per nascondere lunghi elenchi di parametri e ancora evitare effetti collaterali se li costruisci di conseguenza. Ecco un piccolo esempio (in Java, non testato):

class ManyParams {
    final String theName = null;
    final int    theAge = 0:
    ManyParams() {}
    ManyParams(String a, int b) { theName=a; theAge = b; }
    public withName(String n) {
        return new ManyParams(n, this.theAge);
    }
    public withAge(int i) {
         return new ManyParams(theName, i);
    }
}
/// to be used like this
foo(new ManyParams.withName("John").withAge(42));

Ovviamente, il costruttore di ManyParams avrà comunque una lunga lista di parametri in questo modo. Ma è nascosto.