Objeto de solicitud, ¿cuáles son los pros y los contras?

Question

Digamos que tengo el siguiente método:

public Stream GetMusic(string songTitle, string albumName) { ... } 

Un colega mío está convencido de que esta es una mala firma del método. A él le gustaría que yo use un objeto de solicitud, que transformaría la firma del método en esto:

public Stream GetMusic(SongRequest request) { ... } 

Realmente no veo el punto de hacer eso. El único beneficio que veo es que será más fácil agregar parámetros en el futuro. No tendremos que cambiar la firma del método, pero el objeto Request aún tiene que cambiar.

Personalmente, no creo que sea una buena idea. El uso de parámetros hace que sea explícito lo que el método requiere para ejecutar. Además, esto nos obliga a crear otro objeto para poco.

¿Cuáles son los pros y los contras de usar objetos Request? ¿Lo estás usando en tus proyectos y por qué?

Answer 1

Obteniendo datos usando el método GetMusic(...). Si es así, probablemente sería demasiado esfuerzo usar una entidad adicional sin realmente necesitarla.

De hecho, en una situación en la que solo hay un parámetro de entrada, puede usar una clase personalizada. Pero si esa clase es el único lugar para usar, entonces si SongSignature como dice el nombre de clase, tiene que ser usado específicamente para esta clase, eso es una mala práctica de usar "bolsas de parámetros", porque tiene mucha legibilidad.

Además, si alguien estúpida dice que SongSignature debe haber una estructura, y en esa estructura no es un puntero a algunos datos que ser cambiado dentro de método, ese indicador sería en realidad nunca cambia, porque cada vez GetMusic se llama, que tomará una copia de una bolsa de la propiedad.

Incluso si se trata de una clase, debe cambiar el descriptor de acceso para esa clase a public, y en general este no es el mejor método para pasar argumentos a una función y obtener resultados de una función, porque tiene ya está recibiendo una transmisión de ese método.

Supongamos la siguiente situación:

Si en un equipo de un programador reemplaza los parámetros con una clase SongRequest, segundo programador no encontró que se utiliza como un parámetro a una función (porque lucks información en una nombre de una clase), y lo cambió a una estructura en la siguiente iteración, el tercer programador usó este método de tal manera, que tiene que ser una clase (por ejemplo, utilizar referencias de clase dentro de SongRequest) ... Como resultado, no uno realmente sabía por qué algo no funcionaba porque cada uno de ellos tenía domo justo cosa ... No hay excusa para usar una clase para un uso local en lugar de una declaración implícita de parámetros.

En general, usted tiene un buen posibilidades de conseguir una situación de este tipo en un futuro, porque:

• no es el que cambia su código (es decir GetMusic)
• alguien puede revisar el código y encontrar la clase 'SongReqest' es útil (por lo que la situación es aún peor, desde un uso local hasta un uso global de una clase)
• al agregar la clase SongReuest puede agregar dependencias adicionales para su método (si alguien cambia esta clase, lo más probable es que founction no compilará)
• usando SongRequest como property bag lo bloquea solo como una clase, como se mencionó anteriormente.
• el uso de esta clase, método sería probablemente nunca compartirlo parámetros con otras llamadas a funciones (por qué razón?)
• por último, el uso de SongRequest clase sólo para el paso de parámetros para una función específica, da adicional huella de sobrecarga de la memoria, porque si se llama a este método a menudo, por un lado, creará muchos objetos innecesarios en la memoria que tienen que ser recolectados como basura, por otro lado, si tal método se usa raramente, simplemente no será práctico crear una clase para pasar varias variables a una sola llamada

Solo hay una razón real para usar la clase en lugar de un argumento de dos líneas: al programador le gustan esas llamadas y quiere hacer que todos los códigos sean "más bellos que antes", más monádicos, a pesar de que esto no es muy práctico y útil.

Nunca te recomendaría hacer un código como este hasta que quieras que se vea mejor.

En general, supongo que usando una clase personalizada para pasar argumentos para una función es una mala práctica.

Answer 2

Hay una importante ventaja para pasar un objeto -

Si tiene un objeto que se utiliza como parámetro, como SongRequest, el objeto puede ser responsable de su propia validación. Esto le permite simplificar drásticamente la validación en cada método que utiliza el objeto, ya que prácticamente solo necesita comprobar nulo, en lugar de verificar todos y cada uno de los parámetros.

Además, si tiene muchos parámetros, a menudo puede ser más simple generar un solo objeto. Esto es especialmente cierto si encuentra que necesita múltiples sobrecargas para administrar diferentes combinaciones de parámetros.

Dicho esto, cada situación es única. No recomendaría un enfoque sobre el otro para cada situación.