antipatrón antipatrón: estrategias para evitar, antídotos para ayudar a curar

Question

Estoy trabajando en un sitio web de 10 páginas con un back-end de base de datos. Hay más de 500 objetos en uso, tratando de implementar el patrón MVP en ASP.Net. Estoy rastreando la ejecución del código desde una sola página, mi dedo ha estado en F-11 en Visual Studio durante aproximadamente 40 minutos, parece que no hay fin, ¡posiblemente más de 1000 llamadas de método para una página web! Sin embargo, si fueran solo 50 objetos lo que sería una cosa, la ejecución del código serpentea a través de todos estos objetos al igual que millones de hormigas frenéticamente en su gigantesca casa de montículos de tierra, plagada de túneles de objetos. Por lo tanto, nace un nuevo antipatrón: AntFarm.

AntFarm también se conoce como "OO-Madnes", "OO-Fever", OO-ADD, o simplemente adicto al diseño.

Esta no es la primera vez que veo esto, ni mis asociados en otras compañías. Parece que este estilo se está proponiendo activamente, o en cualquier caso es un malentendido de los numerosos evangelios OO/DP dando vueltas ...

Me gustaría presentar un antipatrón para el anti-patrón: GST o "Obtener cosas hechas" también conocido como "Obtener Sh ** hecho" AKA GRD (GetRDone). Este patrón se enfoca en lo que dice, hacer las cosas de una manera simple. Puedo tratar de delinearlo más en una publicación posterior, o por favor comparta sus ideas sobre este patrón de antídoto.

De todos modos, estoy en medio de un gran ejemplo de antipatrón de AntFarm mientras escribo (como extra, no hay documentación ni comentarios). Por favor, comparta sus ideas sobre cómo este anti-patrón se ha vuelto tan predominante, cómo podemos evitarlo, y cómo se puede deshacer o tratar este patrón en un sistema en vivo con el que se debe trabajar.

Answer 1

Creo que Parnas casi lo clavó en On the Criteria to be used in Decomposing Systems into Modules. Cada módulo debe ocultar una decisión de diseño, que puede cambiar en el futuro. En general, un módulo que no tiene nada que ocultar suele ser solo por encima. Él no estaba hablando de clases exactamente, pero creo que el razonamiento todavía se aplica.

Answer 2

Gracias Glomek el artículo es para un espacio de problema interesante, que va al núcleo de lo que es OO, es decir, cómo diseñar sus objetos ... para el éxito o el fracaso, gracias por el enlace.

Ah sí, el diseño antipatrón podría denominarse "Ant Hill", esa es una descripción más clara, creo. Creo que es bastante evidente en este momento, y parece estar creciendo ... Todavía me pregunto cómo podemos alejarnos de él en general, y escribir un código más claro y simple que hace el trabajo con la mínima complejidad necesaria. .

Answer 3

Si es es de hecho debido a un exceso de diseño (y suena como él), entonces aquí hay algunos sinónimos para usted:

Gas Factory
Rube Goldberg máquina
Heath Robinson artilugio

pero mi nombre personal para esto "intentar demasiado F # $% 3n hard". Mis condolencias.

Saludos Adrian

Answer 4

muchos archivos donde se podría hacer. Asqueroso. 500 objetos para 10 páginas web parece una relación loca. ¿Ha considerado ejecutar el análisis de código en la solución? Podría darte algunas estadísticas interesantes con las que luchar.

También llamaría al KISS anti-anti-patrón.

Answer 5

El problema aquí es que su patrón de diseño es, en sí mismo, no OO. Comience con un patrón que no sea de OO, intente implementarlo como "objetos", termina con un desastre.

El hecho de que el sistema esté escrito en un OOPL no hace que el sistema OO.

Answer 6

Si considera que una granja de hormigas es una forma eficiente de explorar un espacio problemático complejo (la granja de hormigas) mediante el uso de agentes simples (las hormigas), entonces esto empieza a parecer decididamente menos antipatrón.

Las críticas de OOP basadas en la complejidad de "ajustarlo todo en la cabeza" siempre ignoran que (a) es difícil ajustar todo en su cabeza (independientemente de si es OO o no) y (b) que OO reduce activamente la necesidad de tenerlo todo en su cabeza de todos modos