Demasiados & # 8220; patrón de sufijos & # 8221; - diseño olor?

Question

Me 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 este un olor a diseño? ¿Debo imponer un límite a este número?

Sé que algunos programadores tienen reglas similares para otras cosas (por ejemplo, no más de N niveles de direccionamiento de puntero en C.)

Todas las clases me parecen necesarias. Tengo un mapa (fijo) de cadenas a fábricas, algo que hago todo el tiempo. La lista se está haciendo 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 de costumbre, evito los Singletons.

Answer 1

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

No puedo ver por qué quería nombrar a una clase 'InstructionBuilderFactoryMapFactory'? ¿Hay otros tipos de fábricas, algo que no cree un mapa de instrucciones de InstructionBuilder? ¿O hay algún otro tipo de InstructionBuildersFactories que deba mapearse?

Estas son las preguntas en las que debes pensar cuando comienzas a crear clases como estas. Es posible simplemente agregar todas esas fábricas de fábricas diferentes a una sola y luego proporcionar métodos separados para crear fábricas. También es posible poner esas fábricas en un paquete diferente y darles un nombre más conciso. Piense en formas alternativas de hacer esto.

Answer 2

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

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

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

Editar:

Encontré un interesante artículo sobre cómo nombrar en Coding Horror, por favor, compruébalo !

Answer 3

Muchos patrones en el nombre de una clase son definitivamente un olor, pero un olor no es un indicador definido. Es una señal de que "pare por un minuto y repiense el diseño". Muchas veces cuando te sientas y piensas que se hace evidente una solución más clara. A veces, debido a las restricciones a la mano (técnicas / tiempo / potencia / etc) significa que el olor debe ignorarse por ahora.

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

Answer 4

He estado pensando lo mismo. En mi caso, la abundancia de fábricas se debe a la compilación para la capacidad de prueba. Por ejemplo, tengo un constructor como este:

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

Aquí tengo un analizador: la clase definitiva que necesito. El analizador se crea mediante métodos de llamada en un constructor. Los constructores (uno nuevo para cada analizador que se debe construir) se obtienen de la fábrica de constructores.

Ahora, ¿qué h ... l es ParserFactory? Ah, me alegro 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 forma de hacerlo sin romper la incapsulación de la clase de analizador en particular que el creador está creando es colocar un punto de intercepción justo antes de que se cree el analizador, para ver qué pasa en su constructor. Por lo tanto ParserFactory. Es solo una forma de observar en una prueba de unidad lo que se 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 lo haría mejor si pudiera tener métodos de clase adecuados en lugar de miembros estáticos. / p>