Arquitectura, muchos métodos y largas listas de parámetros

Question

Estamos tratando de hacer las cosas de la manera más clara y limpia posible en una arquitectura de 3 niveles.

Pero la complejidad de nuestro sistema nos deja confundidos sobre la mejor manera de proceder.

Si utilizamos muchas cadenas de funciones que pasan por la capa de servicio, con listas de parámetros más pequeñas, esto parece claro en términos de lo que se está haciendo, pero parece que se repite una gran cantidad de funcionalidades a través de estos métodos.

Sin embargo, si utilizamos menos métodos y tenemos una gran lista de parámetros para cambiar la funcionalidad dentro de los métodos, esto parece salirse de control.

Nuestra elección por el momento es tener más funciones ya que esto se siente más fácil de manejar que las funciones monolíticas con muchos flujos lógicos dentro de ellas. Esto obviamente significa trozos más pequeños de código más manejable.

Es solo que escuchamos sobre DRY mucho, así que esto parece que hay alguna repetición dentro de los métodos. Pero parece más flexible.

Answer 1

La mayoría de las personas prefiere firmas de métodos más pequeños que las grandes. Hace que sea más fácil razonar sobre los métodos (¡sin mencionar probarlos!), Sin embargo, no debe usar esto para justificar violaciones de los principios DRY.

¿Hay alguna razón por la que no se pueden tener firmas de métodos pequeños y factorizar el código común y replicado en los métodos internos de ayuda?

Answer 2

Supongo que los "muchos métodos" hacen la misma función y lo único que varía son los parámetros.

Mi apporach sería pasar los datos con unos pocos objetos, similar a cómo se pasan los parámetros a GridBagLayout en los objetos GridBagConstraints. Por ejemplo, para una consulta de búsqueda paso un "Filtro" de frijol con todas las condiciones posibles, el código en el método es largo pero no complicado ("es condición X especificada -> agregue filtro X a consulta") y puede dividirse fácilmente en algunas funciones auxiliares.

Answer 3

Realmente creo que para las aplicaciones empresariales no hay nada mejor que una buena arquitectura en capas, con la buena intención de revelar nombres para clases y métodos, y algunos patrones de diseño aplicados en toda la solución. Siguiendo esta regla, es contradictorio tener métodos largos porque probablemente romperán el Principio de Responsabilidad Individual, por lo que no expresarán por su nombre lo que realmente están haciendo. Si desea utilizar el principio DRY, simplemente mantenga sus métodos y clases limpios, cortos y claros, y aplique algunos patrones de diseño para reutilizarlos en toda la solución.

Recomiendo leer Domain Driven Desing (Eric Evans) y Clean Code (Robert C. Martin) para ver más sobre este tipo de "código de filosofía" en detalle.

Answer 4

Suele ser un síntoma de aplicaciones fuertemente acopladas. Para ir de A a B tienes que tomar quince giros y luego retroceder un poco.

Una buena forma de reducir el acoplamiento es introducir eventos de dominio. Por ejemplo, cuando se crea un usuario va a generar un evento de dominio llamado UserCreated cuando está suscrito por la clase SendWelcomeEmail y NotifyAdminsOfNewUser o SendIntroductionaryOffer

El punto es que cualquier persona puede actuar sobre un evento que efectivamente reduce la complejidad, ya que Don Ya tienes que unir fuertemente tu código.

Answer 5

Creo que será mejor proporcionar 2 ejemplos de lo que quieres decir. Parece uno de los siguientes:

1. Tiene un mal diseño.
2. Tiene una interacción/comportamiento extendido a través de muchos objetos.
3. Está utilizando un patrón de diseño DI \ incorrectamente.
4. Su código es realmente de procedimiento y no de OO.

Como no proporcionó ningún ejemplo, lo revisaré en breve para conocer todas estas opciones.

1. Tiene un mal diseño.

3. Está utilizando el patrón de diseño DI \ incorrectamente.

Quizás deba dividir su código de manera diferente, quizás debería usar DI o volver a visitar cómo lo está usando. Tal vez deberías aplicar algunos patrones de diseño para que el problema sea manejable.

2. Tiene una interacción/comportamiento extendido a través de muchos objetos. Considere utilizar el DCI http://alexsmail.blogspot.com/2012/09/dci.html para resolver este problema.

4. Su código es realmente de procedimiento y no de OO. Vi código escrito en Java por el programador que son regulares para escribir código de procedimiento. Tiene muchos parámetros que modifican la ejecución del método. La solución será rediseñar su código y (re) entrenar a sus programadores.