2009-08-24 9 views
5

Tengo una clase de fábrica, DocumentLoaderFactory, que simplemente devuelve una instancia que implementa una interfaz, IDocumentLoader.¿A qué espacio de nombres pertenece una clase de fábrica?

Toda aplicación reside bajo el siguiente espacio de nombres

Skim.Ssms.AddIn.ActiveFileExplorer.Loader

Pero lo que me pregunto es, que pertenece espacio de nombres DocumentLoaderFactory? He colocado la clase de fábrica en el espacio de nombre *.Loader por el momento, pero se está utilizando desde un control de usuario (ActiveFileWindow) del espacio de nombres principal, Skim.Ssms.AddIn.ActiveFileExplorer, como se muestra a continuación.

¿Cuál sería pros & contras de colocar el método de fábrica dentro de *.Loader o es el espacio de nombres principal? Me gustaría tomar una decisión según pros/contras.



Este es el diagrama de mi proyecto alt text

Respuesta

8

Yo diría que es mejor colocar sus fábricas con el tipo (s) que crean. Una fábrica es proveedora de algo, y debe estar asociada y próxima a las cosas que proporciona. Si sigues las reglas de la cohesión, llegarías a la misma conclusión. Las cosas relacionadas deben estar juntas para mantener una API cohesiva.

+0

@jrista: he decidido abandonar la clase de fábrica dentro del espacio de nombres * Loader. Tener el método de fábrica en el espacio de nombres padre parece contaminar la estructura del proyecto. – Sung

+0

Creo que ese es el lugar correcto.:) Si alguna vez decide retirar el espacio de nombres de la Cargador en su propio ensamblaje, no tendrá problemas con las referencias que faltan en la fábrica ni nada de eso. – jrista

2

yo diría que lo deje en la **. * Cargador de espacio de nombres ya que hará que sea más fácil encontrar al trabajar con su IDocumentLoader implementaciones .

+0

Por lo que yo sé, generalmente un objeto no debe invocar/instanciar un objeto/método del espacio de nombres secundario. Pero si tuviera que mover la fábrica al espacio de nombres principal, ¿no sería el método de fábrica el único que accedería a las clases dentro del espacio de nombres secundario? – Sung

+0

¿Por qué dirías eso? No veo una razón por la cual un objeto no puede llamar/instanciar y método/objeto de un espacio de nombres hijo. Realmente depende de cómo quieras que se vea tu API desde el exterior. –

4

Como el código que utiliza las necesidades de fábrica no tiene absolutamente ningún conocimiento de la implementación en el patrón abstracto de fábrica, coloco la interfaz y la fábrica (más cualquier tipo de información) en la raíz, luego las implementaciones en sus propias carpetas (o carpeta si hay pocos).

Así que en su caso tengo algo como:

Loader 
- DocumentLoaderFactory 
- DocumentLoadType 
- IDocumentLoader 


Loader\Implementation 
- NameDocumentLoader 
- TypeDocumentLoader 
- ConnectionDocumentLoader 
- DocumentLoader 

he asumido que DocumentLoader es una clase base abstracta que hereda la interfaz debido a su nombre, pero se entiende la idea. No sé para qué sirve su otra clase, "TreeViewImageIndex", pero podría colocarla en cualquier lugar o en otro lugar completamente diferente si fuera apropiado.

Esto mantiene su código agradable y coherente, no requiere que su clase implementadora conozca el espacio de nombres Loader \ Implementation y permite que su árbol de documentos sea más fácil de leer.

+0

@Odd: Gracias, Impar Sí, DocumentLoader es una clase * abstracta *. Y crear otro espacio de nombres para la implementación es un enfoque que no había pensado – Sung

+0

@Odd: Resumir mediante la introducción de otro espacio de nombres suena sólido pero tener un espacio de nombres demasiado profundo en mi caso no parece valer la pena para mi caso específico – Sung

+0

Está bien, no se ajusta a todos. Personalmente, no me gusta mantener demasiadas clases en un solo espacio de nombres/directorio porque complica mi código y donde puedo separarme lógicamente, lo hago. – Odd

Cuestiones relacionadas