2012-03-30 12 views
5

Estaba mirando un código de un compañero desarrollador y casi lloré. En la definición del método hay 12 argumentos. De mi experiencia ... esto no es bueno. Si fuera yo, habría enviado un objeto de algún tipo.¿Cuáles son las mejores formas de crear un método que requiere muchos argumentos? (10+?)

¿Existe otra/más forma de hacerlo (en otras palabras, cuál es la mejor manera de solucionar esto y explicar por qué)?

public long Save (
    String today, 
    String name, 
    String desc, 
    int ID, 
    String otherNm, 
    DateTime dt, 
    int status, 
    String periodID, 
    String otherDt, 
    String submittedDt 
) 

caso omiso de mi nombres de variables pobres - son ejemplos

+1

¿Están relacionados los argumentos de alguna manera? Si es así, agrúpelos en un objeto que describa la semántica. Espero eso ayude. –

+0

Pensé que esta era una pregunta razonable, ¿por qué hay dos votos para cerrarla? – Cody

Respuesta

5

Depende mucho del idioma.

En un lenguaje sin verificación de tipos en tiempo de compilación (por ejemplo, Python, Javascript, etc.) se debe utilizar argumentos clave (común en Python: se puede acceder a ellos como un diccionario pasa como un argumento) o objetos/los diccionarios pasan manualmente como argumentos (comunes en javascript).

Sin embargo, el "argumento infierno" que describió a veces es "la forma correcta de hacer las cosas" para ciertos lenguajes con comprobación de tipos en tiempo de compilación, porque el uso de objetos ofuscará la semántica del typechecker. La solución entonces sería usar un mejor lenguaje con comprobación de tipos en tiempo de compilación que permite la coincidencia de patrones de objetos como argumentos.

2

Sí, objetos de uso. Además, la función probablemente esté haciendo demasiado si necesita toda esta información, por lo tanto, use funciones más pequeñas.

+1

Eso es lo que pensé. En realidad, solo está insertando datos en una tabla ... – Cody

1

Depende de qué tan compleja es la función. Si hace algo no trivial con cada uno de esos argumentos, probablemente debería dividirse. Si solo los pasa, probablemente deberían ser recogidos en un objeto. Pero si solo crea una fila en una tabla, no es realmente gran cosa. Es menos problemático si su lenguaje admite argumentos de palabras clave.

1

Usa objetos.

class User { ... } 
User user = ... 
Save(user); 

Su decisión proporciona una manera fácil de agregar nuevos parámetros.

0

Imagino que el problema que está experimentando es poder ver la llamada al método y saber qué argumento está recibiendo qué valor. Este es un problema pernicioso en un lenguaje como Java, que carece de algo así como argumentos de palabras clave o hash JSON para pasar argumentos con nombre.

En esta situación, el Builder pattern es una solución útil. Son más objetos, tres en total, pero conducen a un código más comprensible para el problema que describes. Así que los tres objetos en este caso serían como tal:

  1. cosa: entidad con estado, por lo general inmutables (es decir, sólo getters)
  2. ThingBuilder: clase de fábrica, crea una entidad cosa y establece sus valores .
  3. ThingDAO: no es necesario para usar el patrón del generador pero responde a su pregunta.

Interacción

/* 
ThingBuilder is a static inner class of Thing, where each of its 
"set" method calls returns the ThingBuilder instance being worked with 
while the final "build()" call returns the instantiated Thing instance. 
*/ 
Thing thing = Thing.createBuilder(). 
       .setToday("2012/04/01") 
       .setName("Example") 
       // ...etc... 
       .build(); 

// the Thing instance as get methods for each property 
thing.getName(); 

// get your reference to thingDAO however it's done 
thingDAO.save(thing); 

El resultado es que se consigue argumentos con nombre y una instancia inmutable.

Cuestiones relacionadas