+2  A: 

I would say leave it in the *.Loader namespace as it will make it easier to find when working with your IDocumentLoader implementations.

Nathan W
As far as I know, usually an object should not call/instantiate an object/method of child namespace. But if I were to move the factory to the parent namespace, wouldn't the factory method be the only one accessing classes within the child namespace?
Sung Meister
Why would you say that. I don't see a reason why an object can't call/instantiate and method/object of a child namespace. It really depends on how you want your API to look from the outside.
Nathan W
+5  A: 

I would say its best to colocate your factories with the type(s) they create. A factory is a provider of something, and should be associated and proximate to the things it provides. If you follow the rules of cohesion, then you would come to the same conclusion. Related things should be close together to maintain a cohesive API.

jrista
@jrista: I have decided to leave the factory class within *Loader namespace. Having the factory method in the parent namespace seem to pollute the project structure.
Sung Meister
I think thats the right place. :) If you ever decide to pull the Loader namespace off into its own assembly, you won't run into problems with the factory missing references or anything like that.
jrista
+3  A: 

Because the code that uses your factory needs have absolutely no knowledge of the implementation in the abstract factory pattern, I usually put the interface and the factory (plus any type information) into the root, then the implementations into their own folders (or folder if there are few).

So in your case I have something like:

Loader
- DocumentLoaderFactory
- DocumentLoadType
- IDocumentLoader


Loader\Implementation
- NameDocumentLoader
- TypeDocumentLoader
- ConnectionDocumentLoader
- DocumentLoader

I've assumed that DocumentLoader is an abstract base class that inherits your interface because of it's name, but you get the idea. I don't know what your other class "TreeViewImageIndex" is for but you could put it in either place or somewhere completely different if it's appropriate.

This keeps your code nice and cohesive, does not require your implementing class to know about the Loader\Implementation namespace and lets your document tree be easier to read.

Odd
@Odd: Thanks, Odd. Yes, DocumentLoader is an *abstract* class. And creating an another namespace for the implementation is an approach I have not thought about
Sung Meister
@Odd: Abstracting by introducing another namespace does sound solid but having a too deep of a namespace in my case doesn't not seem to be worth the trouble for my specific case.
Sung Meister
That's fine, it doesn't suit everyone. I personally don't like to keep too many classes in a single namespace / directory because it clutters up my code and where I can logically separate, I do.
Odd