design - strategy - patrones de diseño java

¿Cuándo puede un patrón de diseño empeorar su software? (19)

¿Cuándo puede un patrón de diseño empeorar su software?

He visto un programa donde usaron el patrón de fachada entre la GUI y la lógica. Consideraron que no se pueden transportar objetos sobre esto, por lo que solo se usaron tipos primitivos que dificultaban el código.

Cualquier patrón que se malinterprete o aplique incorrectamente tenderá a empeorar el código, no mejor. Además, cualquier patrón que se aplique solo por el patrón, por ejemplo, "¡Ahora somos SOA!". Generalmente, si un patrón introduce un " olor codificado ", entonces su uso debe ser sospechoso.

Cuando es el patrón incorrecto para su problema.

Cuando lo usa mal, o, a veces peor, cuando usa un patrón innecesariamente. Esto último me vuelve loco porque cuando analizo un fragmento de código, naturalmente, primero asumo que hay una razón para todo lo que hay allí, y cuando no veo una razón para algo, la suposición predeterminada más segura es que me falta algo. Y como no quiero arriesgarme a descifrar el código de forma desconocida o impredecible, pierdo el tiempo tratando de descubrir por qué está ahí antes de meterme con él.

Cuando su nombre es singleton

El software empeorará cuando use patrones de diseño como bloques de construcción absolutos, en lugar de como planos azules para ayudar a resolver problemas de codificación.

No estaban destinados a ser los bloques en los que se enmarca el problema. No deberían aparecer en las convenciones de nomenclatura de objetos. Los objetos no deben llamarse * Factory o * Singleton, o cualquier otro nombre de patrón. No deberían estar bloqueados a un patrón específico.

Son realmente buenos "puntos de partida" para ayudar a construir código complejo más rápidamente. Puede (y debe) mezclar y combinar las ideas según sea necesario. ¿Documentación? Para eso están los comentarios, no el espacio de nombres del objeto ...

Pablo.

En general, cuando un codificador toma la actitud de que los patrones son los ladrillos tipo lego con los que se construye un software, se obtiene un código realmente extraño.

Es interesante que, durante el año pasado, he invertido una gran cantidad de tiempo aprendiendo Patrones de diseño y sus implementaciones, así como parece haber una recuperación cada vez mayor contra los patrones de diseño. Los patrones de diseño se han unido, justamente o no, a los rangos de procesos y metodologías que se suponía debían hacer que el software fuera una habilidad cuantificable, es decir, la falacia de que usarlos te haría escribir un mejor código. Creo que el problema con Design Patterns es que los programadores menos hábiles los usan como un "Golden Hammer". Aprenden el patrón de estrategia, que es algo valioso, pero luego lo usan en todas partes , complicando su código y agregando características innecesarias y "capacidad de expansión".

Creo que hay un gran valor en la refactorización de patrones, porque estás limpiando el código existente. Los patrones también son herramientas de comunicación valiosas, que le permiten describir su código en términos de nivel superior. Pero rellenar patrones de diseño en su software porque son geniales y comercializables (también conocido como "desarrollo dirigido por el currículum") es una mala idea.

Levi, solo usaría un patrón específico si hacía que mi vida (y las que son responsables de mantener el código) me resultara más fácil. Creo que la selección adecuada de patrones de diseño es tan importante como los comentarios. ¿Quizás los comentarios son más importantes? Encontrará que los patrones de diseño, en su mayor parte, describen formalmente las técnicas que nosotros, como desarrolladores, hemos utilizado durante años.

TheEruditeTroglodyte

Lo que hace que sea más fácil (EJB)

Obviamente, cuando abusa de un patrón, solo empeora su diseño.

Puedo pensar de muchas maneras en que un patrón de diseño puede salir mal. El libro de GoF explica el problema, la solución y los inconvenientes de todos los patrones de los que habla. - Un patrón es la solución a un problema. Si ese problema no es tu problema, entonces es probable que se convierta en un antipatrón. - Un patrón tiene inconvenientes, y debes ser consciente de ellos. - Cuando no lo necesitas. Un patrón puede implicar muchas clases, y está tratando de resolver un problema que pueda tener en el futuro pero que todavía no tiene. - Si no entiende cómo funciona y lo implementa mal, también se convierte en un antipatrón. Vas a terminar con muchas clases y códigos inútiles. - Cuando empiezas a ser adicto a ella. Las jerarquías que son demasiado profundas, el mal uso de polimorfismo o singletons, etc. pueden plantear un problema.

Probablemente haya otras razones también ...

Un patrón de diseño es simplemente una forma de nombrar y documentar una estructura de código común. Como tal, no debes concluir que todos los patrones son buenos. Las personas que hacen un buen trabajo al documentar los patrones de diseño (por ejemplo, el GoF) siempre incluyen una sección en la descripción del patrón que describe cuándo debe, y no debe, usar el patrón. Como tal, la mitad del punto de la mayoría de los libros de patrones de diseño es responder a la pregunta "¿Cuándo puede un patrón de diseño empeorar su software?"

Muchos desarrolladores inexpertos nunca se molestan en aprender la sección de usos apropiados y terminan aplicando patrones donde no son apropiados. Creo que esta es la causa de gran parte de la negatividad que rodea los patrones de diseño.

En conclusión, la respuesta a esta pregunta debería ser: - Ir y leer el patrón de diseño y se lo dirá.

Un patrón de diseño puede empeorar su software si lo usa incorrectamente y lo aplica en una situación incorrecta . El sentido común debería ser el compañero perfecto para un patrón de diseño.

El mal uso de los patrones a veces se asocia con una falta de comprensión de las fuerzas asociadas con el problema y el patrón de solución propuesta para ese problema. Además, la intención del patrón podría malinterpretarse y conducir a usos indebidos.

Para una mejor comprensión de los patrones, también debe aprender sobre el concepto de Antipatrón y leer mucho más que el libro de GOF. Una sugerencia es leer Pattern Hatching para complementar los conceptos de GOF.

Yo diría que cada vez que elija un patrón basado en la solución de un problema, y no todos los problemas que su software intenta resolver.

Por el contrario, tratar de sobre-diseñar una solución que se adapte a todos los posibles casos de uso posibles puede llevarlo a utilizar un patrón de diseño demasiado voluminoso para adaptarse a la mayoría de sus casos de uso.

Entonces, el patrón / nivel ideal de adherencia a ese patrón sería algo que se encuentra entre los dos extremos.

Creo que el patrón de estrategia puede empeorar el software si no es necesario. El patrón de estrategia básicamente hace que una pieza de funcionalidad sea "conectable", lo que significa que podemos cambiar diferentes implementaciones sobre la marcha. Pero esta funcionalidad conectable a menudo agrega mucha complejidad (y algunas veces gastos adicionales) con la configuración, y si no es necesaria, es un desperdicio. Veo este patrón abusado con bastante frecuencia.

Cuando las personas analizan el código y pasan más tiempo tratando de entender el patrón que la lógica de negocios. Los patrones son buenos, pero solo si todos los involucrados saben cómo leerlos.

Puede leer sobre antipatterns aquí , por ejemplo.

Se llama antipatrón y consulte el manual AntiPatterns: Refactoring Software, Architectures y Projects in Crisis para ver ejemplos.

Durante décadas, los programadores a menudo han pasado tiempo empeorando el software al aplicar prácticas que no entienden, en lugar de aprender por qué esa práctica es buena. El uso de ciertas herramientas / palabras clave / frameworks puede hacer que un programador se sienta sofisticado, cuando solo está jodiendo cosas. Algunos ejemplos comunes:

Lanzar muchos bloques try / catch / finally puede hacer que un programador sienta que tiene un esquema de manejo de errores, cuando en realidad no es así.
La sustitución de sql con procedimientos almacenados puede hacer que los programadores sientan que tienen una capa de acceso a datos que mágicamente les da eficiencia, reutilización, encapsulación, cuando en realidad no es así.
El uso de clases hace que muchos programadores crean que están participando en programación orientada a objetos, cuando de hecho no lo son (o solo están rascando la superficie de OO).

Esta lista podría continuar para siempre. Esta tendencia siempre ha existido y siempre lo será, porque los humanos siempre buscamos atajos. Vemos esto mucho con los patrones ahora porque los patrones son actualmente populares. El problema de raíz es el mismo: los desarrolladores no tienen respeto por cuán complicado es el desarrollo de software, y pensar que un patrón o práctica implementada a ciegas es un sustituto del aprendizaje y la humildad.

¿La solución? Dificil de decir. No se puede equivocar al entregar un desarrollador junior Code Complete o algo así, para ayudarlos a entender que esto se trata de aplicar principios a situaciones particulares , y que los grandes desarrolladores lo mantienen simple.