Campos vs argumentos del método [cerrado]

Acabo de comenzar a escribir una nueva clase y se me ocurrió que estaba agregando muchos argumentos de métodos que no son estrictamente necesarios. Esto sigue un hábito para evitar tener un estado en las clases que es específico para alguna llamada de método, en lugar de ser una configuración general o dependencias de la clase.

Hacerlo significa que muchos métodos que no pueden tener argumentos terminan en uno, dos o tres.

Me gustaría escuchar sus opiniones sobre lo que piensa de esta compensación, y cómo decide qué enfoque adoptar en cada situación.

Dado que el código es a menudo más fácil de entender que el inglés al describir el código, creé una pequeña esencia que tiene ambas variantes: https://gist.github.com/JeroenDeDauw/6525656

Dado que el único método externo visible de su ejemplo es updateTable, creo que está bien usar campos en lugar de parámetros de método.

Si esto es parte de una clase más genérica (por ejemplo TableTools), movería los métodos auxiliares que necesitan el estado a una clase interna oculta.

Ejemplo de pseudocódigo:

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

     private class TableUpdater { ... }
}

De esta forma, evita los campos que se utilizan solo con un método público. Además, el código es seguro para subprocesos en el sentido de que cada llamada a updateTable usa su propia copia de TableUpdater y, por lo tanto, de las variables de instancia de TableUpdater.

El uso de campos coopta la capacidad de tener subprocesos múltiples disponibles para los métodos que usan esos campos.

Usar campos como este es solo un poco mejor que usar globales desde un punto de vista de reutilización y mantenibilidad, el punto clave aquí es que las configuraciones complejas necesitan documentación cuidadosa y actualizada sobre qué métodos usan y / o controlan qué campos; algo que no necesita hacer cuando usa argumentos.

En palabras simples:

• los métodos deben tener la menor cantidad de argumentos posible (Martin's Clean Code)
• Una de las características de los objetos es que pueden (y deberían) tener un estado
• Los métodos no estáticos que no funcionan en el estado del objeto, es decir, reciben todo como parámetros, no son cohesivos
• los métodos no cohesivos también podrían hacerse estáticos y agruparse en una clase de utilidad

Nuevamente, en mi humilde opinión, los métodos no cohesivos pertenecen a una clase de utilidad y no a una clase con un nombre de dominio.

¡No uses campos en el caso actual! Dos "hilos" que usan el objeto al mismo tiempo se confundirán seriamente. No tienen que ser reales, hilos separados tampoco (de ahí las citas). Si configura el objeto para una tabla, luego llame a un método que lo usa para otra tabla, luego intente usar la configuración original, tiene un problema. Quédese con los parámetros por el momento.

Lo que quiere hacer aquí es crear una nueva clase de actualización que se use en un solo caso. La clase original podría tener un método para crear una instancia cuando sea necesario. La nueva clase tendría campos. Tienes lo mejor de ambos mundos. A veces es más simple seguir los parámetros, pero en su ejemplo ya está llegando a donde una clase separada sería mejor.

Creo que la elección debe estar de acuerdo con la situación real, tal como la ves. Si un elemento pertenece a una instancia, debe verse como su campo. Si el elemento es externo a la instancia, debe pasarse como un parámetro de método.

Deberíamos guiarnos en este caso no por la efectividad (la diferencia es insignificante de todos modos), o (¡Dios salve!) La facilidad de escribir, sino por la comprensibilidad y la naturalidad del código.

En mi opinión, si está escribiendo código que hace algo a algo, entonces debe tomar parámetros que definan a qué cosas debe hacerles y su nombre debe definir lo más posible lo que le hace.

Si está escribiendo código que empaqueta una acción para que se realice en algo, entonces debe envolver las cosas que se deben realizar en un objeto y pasarlas a lo que hace algo .

Esta acción se convierte en una especie de metadescripción de las llamadas a los métodos de la primera que luego puede realizar en una fecha posterior haciendo cola o incluso decide no hacerlo por alguna razón.

Entonces su pregunta se traduce en ¿ es una Acción o una Función ? Una Acción puede posponerse o cancelarse y, por lo tanto, debe encapsular aquello sobre lo que actúa. Una función ocurre inmediatamente, por lo que no es necesario preservar sus parámetros.

Puede deshacer y Acción, pero no una Función .