La mejor práctica para evitar “tocar el teléfono” con argumentos del constructor

7

Encuentro que la encapsulación requerida por OO me hace pasar frecuentemente a los paramenters de padres a hijos, de bisnieto a segundo nieto nieto, una vez eliminado (no realmente tan malo). Pero, inevitablemente, en el proceso, y especialmente si se trata de gráficos, habrá una confusión por la tercera iteración de someConstructor(int minX, int minY, int maxX, int maxY) .

Encontré al menos una pregunta aquí que sugiere que los objetos de parámetros son la solución. Esto me parece más un kludge diseñado para satisfacer un fetiche de bajo conteo de parámetros que realmente útil. Además, en estos escenarios, generalmente estoy cortando los números en partes más pequeñas (de pantalla) con cada paso.

Se me ocurre si estas llamadas de constructor se organizan línea por línea más arriba en la cadena, tendré comparaciones fáciles. Pero esto parece perder toda apariencia de OOPiness. En mi aventura más reciente con las mediciones de encontrar la transposición, estaba dibujando un teclado musical. No quiero que la vista principal sepa o importa qué es exactamente la tecla G # o qué es exactamente.

Entonces, ¿mejores prácticas? Por favor, no digas, ve más lento, sé menos descuidado.

    
pregunta anthropomo 02.01.2013 - 07:06

2 respuestas

11

Para ampliar el comentario de @ 9000, usaría objetos que brindan más información y, posiblemente, verificación de errores sobre sus argumentos. Por ejemplo, en lo siguiente:

drawLine(100, 20, 300, 30);
drawLine(new Point(100, 20), new Point(300, 30));

El segundo es generalmente más legible. Puede verificar errores (¿pueden ser negativas las coordenadas? ¿Puede un rectángulo tener un ancho o una altura negativos?) Y proporciona una forma más fácil de acceder a los métodos de ayuda (como la conversión de sistemas de coordenadas o transformaciones afines). Además, si se pasa una gran cantidad de datos (como una lista de puntos para una polilínea), terminará pasando referencias de objetos en lugar de toda la estructura de datos.

    
respondido por el akton 02.01.2013 - 08:43
3

No estoy completamente seguro de cómo se ve tu jerarquía de clases, pero te daré mis ideas sobre la construcción de objetos y cómo he comenzado a diseñar mis clases en los proyectos en los que trabajo.

  • Herencia o composición: Parece que está asumiendo que, debido a que está programando en un estilo OO, siempre debe usar la herencia; Esto simplemente no es cierto. Depende de usted, el diseñador, determinar qué solución resuelve mejor su problema. A continuación, te daré un ejemplo de composición en lugar de herencia.

  • Objetos de parámetros (como lo colocas): cuando diseñas una clase, estás modelando tus datos según cómo se ve en tu cabeza; Le estás dando un nombre y una estructura. Un ejemplo simple sería una clase llamada Point2D que tendría una X y una propiedad Y asociadas con esa clase. Lo bueno de crear este "objeto de parámetro" es que ahora puede crear funciones o métodos que operen en ese objeto. No creo Point2D con un constructor, hago una segunda clase llamada Point2DFactory con un método estático Crear (x, y). Esto hace 2 cosas por mí, mantiene el peso ligero de mi clase Point2D y pone toda la lógica para crear un Point2D en un solo lugar. Ahora puedo componer un Point2D de cualquier forma que lo desee y el Point2D ya no es responsable de ser un punto y saber cómo se crea un punto. No está vinculado a alguna cadena de herencia, es el trabajo de Point2DFactory preocuparse por eso.

  • Inversión de control: Si necesita encapsular algo de la funcionalidad de archivado en un solo objeto que se puede dividir en poca funcionalidad, puede usar una inversión del marco de control para ayudarte. Lo que hace es tomar todos esos "objetos de parámetros" que ha creado (con suerte con interfaces abstractas) y descubrir cómo construir el objeto que necesita al inyectar la funcionalidad en su constructor.

Si está creando constructores que dependen de algunos cálculos matemáticos para generar sus parámetros, considere crear un objeto de parámetro y una fábrica que lo cree. Luego, puede hacer otra fábrica que cree su objeto deseado basándose en cualquier entrada que desee. ¿Puedes decir que uso mucho el patrón de fábrica: P? Espero que lo que he dicho le muestre que crear más objetos no es algo malo (OOP lo requiere: /) y si puede hacer que cada clase / objeto tenga solo una responsabilidad, su base de código general será extremadamente flexible y una placer de mantener.

EDITAR en respuesta al comentario: Tal vez no entiendo exactamente lo que está preguntando. Pensé en tu problema qué constructores anidados tienen nombres de entrada similares. A lo que intentaba llegar es que, en general, un padre no debería necesitar saber cómo instanciar sus objetos hijos. Eso hace a su padre responsable de hacer lo que sea que el padre hace Y para crear los objetos secundarios. Si el propósito del alma del padre es crear los objetos secundarios, eso se denomina fábrica en términos de patrón de diseño. En lugar de encadenar constructores, tire de esa lógica que crea instancias de objetos secundarios fuera de los constructores. Esto le proporciona una usabilidad más flexible de la lógica que crea objetos secundarios y una mejor adhesión a los principios de SOLID.

    
respondido por el mortalapeman 02.01.2013 - 09:35

Lea otras preguntas en las etiquetas