2009-04-01 1 views
5

Seguramente algunos de ustedes se han ocupado de este. Suele suceder cuando los programadores se toman demasiado por OO y se olvidan del rendimiento y tienen una base de datos.¿Cuál es el nombre de este antipatrón?

Por ejemplo, supongamos que tenemos una tabla de correo electrónico y que necesitan ser enviados por este programa. En el arranque, busca cualquier cosa que necesita ser enviada de la siguiente manera:

Emails = find_every_damn_email_in_the_database(); 
FOR Email in Emails 
    IF !Email.IsSent() THEN Email.Send() 

Ésta es una mercancía de un-no-repeat-hágalo usted mismo punto de vista, pero a veces es inevitable y que debe ser:

Emails = find_unsent_emails(); 
FOR Email in Emails 
    Email.Send() 

¿Hay un nombre de este?

+1

Estoy seguro de que obtendrás muchas respuestas diciéndote que el rendimiento ya no es importante. :) – BobbyShaftoe

+0

No estoy seguro de qué OO sobreactuación tiene que ver con esto? –

+0

@MB: Supongo que preguntar al correo electrónico si se ha enviado es OO, mientras que el enfoque sin OO estaría mirando las columnas directamente. –

Respuesta

9

Voy a intentarlo y acuñar el nombre "el patrón de filtro perezoso (anti)".

+0

Marcó esta como la respuesta aceptada por votación popular –

0

Stoopid Aficionados.

En serio, solo he visto este en personas con títulos en informática y ninguna experiencia profesional en absoluto. Cuando enseñaba en Duke, mi asesor y yo organizamos una clase de "Programación a gran escala" en la que hacíamos que las personas observaran exactamente este tipo de errores.

1

No estoy seguro de que esté necesariamente relacionado con la base de datos, ya que podría tener un procedimiento complejo y costoso (por ejemplo, más que un indicador) para aplicar un filtro para un grupo.

No creo que tenga un nombre, ya que el primer diseño simplemente no es bueno, y viola el principio de responsabilidad única. Si busca, filtra e imprime el filtrado, está haciendo varias cosas, por lo que necesita refaccionarlo en "filtrado buscado" e imprimir.

Lo único diferente a una simple refacturación aquí es que también afecta el rendimiento, de la misma manera que los circuitos internos pueden diseñarse de manera que dañan el rendimiento.

0

El rendimiento del primero en realidad puede estar bien, dependiendo del tipo de Emails. Si solo se trata de un iterador (piense en std::vector::begin() en C++), entonces está bien y es mejor que almacenar primero todos los correos no enviados en algún contenedor.

+0

En cuyo caso el nombre de 1800 Information sigue siendo correcto. ¡Los filtros perezosos eficientes son eficientes! –

+0

Mi punto era que todos los registros fueron arrastrados a la aplicación desde el DB sin una buena razón. –

+0

Es tonto buscar todos los correos electrónicos de la base de datos cuando la mayoría han sido enviados cuando el DBMS puede hacer el filtro y solo transferir aquellos que no han sido enviados. -1. –

5

Lo vi una vez. Ese programador no estuvo por mucho tiempo.

Llamamos a eso el "método firehose".

0

Este antipatrón tiene varios nombres posibles.

  • "no-sé-SQL" antipatrón
  • "fascista-DBA" antipatrón
  • "Lo-lo hace-'latency'-media?" antipattern
2

Para mí es leaky abstraction de Joel Spolsky.

No es exactamente un anti-patrón, pero quien escribió este código, realmente no entendía dónde se filtra la abstracción del patrón de Active Record.

+0

Este código me hizo pensar en ActiveRecord también, pero el pseudo-código no es ruby ​​(tendrían "Email.send a menos que Email.sent" por ejemplo). ¿Cómo se maneja la fuga de abstracción de ActiveRecord para la iteración? –

+0

El pseudocódigo no está destinado a ser nada en particular.La primera vez que vi esto fue en C++ –

+0

Sí, Active Record es un patrón genérico que podría implementarse en cualquier idioma. Ruby on Rails tiene una implementación bien conocida. También se llama a veces una "Clase de Entidad". –

1

parecen haber derivado de los siguientes anti-patrones:

El desarrollador original habría posiblemente no le ha permitido escribir los find_unsent_emails() implementación y por lo tanto, habría reutilizado la función enana. Y luego, ¿por qué cambiarlo después del desarrollo y las pruebas?

2

Yo llamo a eso "El enfoque de escopeta".

1

Esto es frecuentemente debido a que es mucho más fácil usar una consulta existente y luego filtrar en código que obtener una nueva consulta SQL agregada. Tal vez porque los DBA controlan todas las consultas y obtener una nueva consulta aprobada lleva días, o tal vez porque la herramienta ORM que está utilizando hace que sea muy difícil definir sus propias consultas personalizadas.

Si tuviera que llamarlo, lo llamaría el patrón "Easy Way Out" (anti). Si es un antipattern o no realmente depende de la situación individual. Si siempre será un número bastante pequeño de elementos que necesita recuperar, hacer el filtrado en el código realmente no es un gran problema. Pero si el número de artículos es grande y tiene el potencial de crecer continuamente, entonces obviamente el filtrado debería hacerse en el servidor.

1

He visto problemas similares en otros lugares, donde en lugar de una simple serie de cosas, había un "clúster de transacciones" basado en un "clúster de listas" basado en un "clúster de recopilación" basado en un "clúster de memoria" ". No hace falta decir que lo más simple se convirtió en un gran negocio.

Lo llamé galopando generalidad.

0

Inspirado en parte por el "patrón del filtro perezoso (anti)" de 1800, ¿qué tal "programación disfuncional" (es decir, lo opuesto a la programación funcional)?

Cuestiones relacionadas