Hi,

Imagine you having some objects (let's call them Dogs) that you need to create in order to let your program work. Normally you would create a Dog in something like a PetStore. However, in this imaginary case, you don't know where to put Dog's creation (you don't know the information expert)! So, I see two solutions here:

1. Create Dogs in your (top) client code (like in sub Main() ). For example, in the start of your "process", program, service, etc... Finally, our client code will create and talk to/combine all the objects which does not have any "expert". IMO this is inevitable, as you have to start somewhere.

2. Create Dogs in a encapsulated Dog "creator" class. The client code will then get the Dogs from this class and from there it can talk to/combine the Dogs. Other objects without an "expert" also have such creator classes, so that the client code only talks to/combine these classes, and not create AND talks to/combine them.

IMO, the second solution is better, as this divides responsiblity over multiple objects and assign only one responsibility to the client code (am I right??). However, and now comes the problem, what in the world do you call such "creator" classes? I have been thinking about calling them "Builders" (eg. DogBuilder), but that suggest I am using the Builder pattern, which I am not using (am I?). I also thought about calling them "Factories" (eg. DogFactory), but the same problem as above: I am not using the Factory Method Pattern. What about a "SimpleDogFactory"? Is THAT what I am using? Perhaps I should just use the name "DogCreator" or KISS: use solution 1.

So, again, I am just nit-picking of something that might not be worth paying any attention at all. But hey, if I don't settle this matter now, I will keep asking myself this question my whole life: do you realize how many hours it would safe me on a live-time base if you helped me out here ?! So... what about it?

How 'about one of these:

• dogHouse
• dogKennel
• dogPen
• doggieHeaven
• dogPark

...ok enough...