Lista larga de parámetros versus lista larga de variables de estado

En un libro de C ++, el autor dice que ya no necesitamos una función con una larga lista de parámetros porque la mayoría de los parámetros se pueden refactorizar en variables de estado en una clase. Por otro lado, un libro de programación funcional dice que las variables de estado son malas porque causa efectos secundarios que provocan código propenso a errores y difícil de paralelizar. Me estoy confundiendo. ¿Debería el código evitar confiar lo más posible en las variables de estado moviendo su variable de estado a la lista de parámetros de función?

Depende de si está programando en un paradigma proceduralo functional. Se requiere un estado mutable para el primero y paralizante para el segundo. Esto es manzanas y naranjas. ¡Ambos son correctos en sus bailiwicks!

Puede aplicar una sola asignación y otras técnicas funcionales a los lenguajes de procedimiento imperativos, el estado inmutable hace que la programación concurrente sea más determinista, pero hacer que cada objeto sea inmutable en un lenguaje como Java o C ++ es casi imposible porque sus modelos de memoria no admiten este paradigma fácilmente.

Si entiendo bien su pregunta, ¿se está preguntando qué condiciones califican el uso de un parámetro o una variable de clase / miembro / campo / etc.? Supongo que te estás refiriendo a un método y no a una función. Si se trata específicamente de C ++, sugiero mover su pregunta para desbordar la pila.

Una larga lista de parámetros puede ser una señal de que podría necesitar refactorizar su método en un conjunto de más granulares. En general, el uso de parámetros hará que su código esté más débilmente acoplado. No estoy seguro de si esto es cierto para la mayoría de los lenguajes OO modernos, pero la creación de objetos puede ser costosa, especialmente si hay muchas variables de clase involucradas; por lo tanto, si las variables de su clase eran objetos y se hace referencia con frecuencia en un programa, entonces pueden justificarse como variables de clase.

También:

• ¿Podrían otros métodos hacer uso de las variables de clase? En caso afirmativo, considere ir con variables de clase.
• ¿Tu método es público? Si es público, use parámetros.
• ¿Puede su lista de parámetros representarse adecuadamente como un hash / map / array / collection / list / etc? Si es así, considérelo una opción.
• ¿Es su método estático? En caso afirmativo, use los parámetros.

No, las variables de estado per se no causan efectos secundarios.

Llamar a un método de establecimiento (en una estructura de datos que es visible en otro lugar) es un efecto secundario.

Puede tener estructuras de datos para ocultar largas listas de parámetros y evitar efectos secundarios si los construye en consecuencia. Aquí hay un pequeño ejemplo (en Java, no probado):

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));

Por supuesto, el constructor de ManyParams todavía tendrá una larga lista de parámetros de esta manera. Pero está escondido.