Demasiados "sufijos de patrón": ¿olor a diseño?

Question

Acabo de crear una clase llamada "InstructionBuilderFactoryMapFactory". Eso es 4 "sufijos de patrón" en una clase. Inmediatamente me recordó esto:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

Es éste un olor diseño? ¿Debo imponer un límite a este número?

sé que algunos programadores tienen normas similares para otras cosas (por ejemplo, no más de N niveles de indirección de puntero en C)

Todas las clases parecen necesarias para mí. Tengo un mapa (fijo) de cadenas a fábricas, algo que hago todo el tiempo. La lista es larga y quiero sacarla del constructor de la clase que usa los constructores (que son creados por las fábricas que se obtienen del mapa ...) Y, como siempre, evito Singletons.

Answer 1

Lo veo como un olor de diseño: me hará pensar si todos esos niveles de abstracción están tirando de suficiente peso.

No veo por qué quería nombrar una clase 'InstructionBuilderFactoryMapFactory'? ¿Hay otros tipos de fábricas, algo que no cree una InstructionBuilderFactoryMap? ¿O hay algún otro tipo de InstructionBuildersFactories que necesite ser mapeado?

Estas son las preguntas que deberías tener en cuenta cuando comiences a crear clases como estas. Es posible agregar todas las fábricas de fábrica diferentes a una sola y luego proporcionar métodos separados para crear fábricas. También es posible poner esas fábricas de fábrica en un paquete diferente y darles un nombre más sucinto. Piensa en formas alternativas de hacer esto.

Answer 2

Muchos de los patrones en el nombre de una clase es definitivamente un olor, pero un olor no es un indicador definitivo. Es una señal para "detenerse por un momento y replantear el diseño". Muchas veces cuando te sientas y piensas que una solución más clara se vuelve aparente. A veces, debido a las limitaciones a mano (técnico/tiempo/poder del hombre/etc.) significa que el olor debe ser ignorado por el momento.

En cuanto al ejemplo específico, no creo que las sugerencias de la galería de maní sean una buena idea sin más contexto.

Answer 3

Un buen consejo es: su API pública de clase (y que incluye su nombre) debe revelar la intención, no la implementación. A mí (como cliente) no me importa si implementó el patrón del generador o el patrón de fábrica.

No solo el nombre de la clase se ve mal, sino que tampoco dice nada sobre lo que hace. Su nombre se basa en su implementación y estructura interna.

Raramente utilizo un nombre de patrón en una clase, con la excepción de (a veces) Fábricas.

Editar:

encontrado una interesante article sobre el nombramiento de Codificación de horror, por favor echa un vistazo!

Answer 4

He estado pensando lo mismo. En mi caso, la abundancia de fábricas es causada por "construir para la capacidad de prueba". Por ejemplo, tengo un constructor de esta manera:

ParserBuilderFactoryImpl(ParserFactory psF) { 
... 
} 

Aquí tengo un programa de análisis - la clase último que necesito. El analizador se crea llamando métodos en un generador. Los constructores (uno nuevo para cada analizador sintáctico que debe construirse) se obtienen de la fábrica del generador.

Ahora, ¿qué es h ... l es ParserFactory? Ah, me alegro de que hayas preguntado! Para probar la implementación del generador de analizadores, necesito llamar a su método y luego ver qué tipo de analizador se creó. La única manera de hacerlo sin romper la encapsulación de la clase de analizador particular que está creando el constructor es poner un punto de interceptación justo antes de que se cree el analizador, para ver qué entra en su constructor. Por lo tanto, ParserFactory. Es solo una forma de que observe en una prueba unitaria lo que pasa al constructor de un analizador.

No estoy muy seguro de cómo resolver esto, pero tengo la sensación de que sería mejor pasar las clases en lugar de las fábricas, y Java haría mejor si pudiera tener los métodos de clase adecuados en lugar de los miembros estáticos.