Elenco di parametri lunghi rispetto a un elenco di variabili con stato lungo

In un libro C ++, l'autore afferma che non abbiamo più bisogno di una funzione con un lungo elenco di parametri perché la maggior parte dei parametri può essere rifattorizzata in variabili di stato in una classe. D'altra parte, un libro di programmazione funzionale afferma che le variabili di stato sono malvagie perché causano effetti collaterali che causano un codice soggetto a bug e difficile da parallelizzare. Mi sto sconcertando. Il codice dovrebbe evitare di affidarsi il più possibile alle variabili di stato spostando la sua variabile di stato nell'elenco dei parametri delle funzioni?

Dipende se stai programmando in un proceduralo un functionalparadigma. Lo stato mutevole è richiesto per il primo e paralizzante per il successivo. Sono mele e arance. Sono entrambi corretti nei loro bailiwick!

È possibile applicare singoli compiti e altre tecniche funzionali a linguaggi procedurali imperativi, lo stato immutabile rende più deterministica la programmazione concorrente, 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, ti stai chiedendo quali condizioni qualificano l'uso di un parametro o una variabile di classe / membro / campo / ecc? Suppongo che ti riferisci a un metodo e non a una funzione. Se si tratta in particolare di C ++, ti suggerisco di spostare la tua domanda nello stack di overflow.

Un lungo elenco di parametri può essere un segnale che potrebbe essere necessario riformattare il metodo in un insieme di più granulari. Generalmente, l'utilizzo dei parametri renderà il tuo codice più liberamente accoppiato. Non sono sicuro che questo sia più vero per la maggior parte dei linguaggi OO moderni, ma la creazione di oggetti può essere costosa, soprattutto se sono coinvolte molte variabili di classe; quindi, se le variabili di classe erano oggetti e venivano referenziate frequentemente in un programma, allora potrebbero essere giustificate come variabili di classe.

Anche:

• 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, utilizzare i parametri.
• Il tuo elenco di parametri può essere adeguatamente rappresentato come hash / map / array / collection / list / etc? In tal caso, consideralo un'opzione.
• Il tuo metodo è statico? In caso affermativo, utilizzare i parametri.

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

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

Puoi avere strutture di dati per nascondere lunghe liste di parametri e 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));

Naturalmente, il costruttore di ManyParams avrà comunque un lungo elenco di parametri in questo modo. Ma è nascosto.