This looks to me like we are talking about Abstract Factory here, not Factory Method.
Anyway, the main reason to use an Abstract Factory is when you want to decouple the decision on *what* exactly to create, and *when* (or *how many* instances) to create.
So, typically, the client who calls the create method will *not* also instantiate the factory. The factory will be created outside and passed into the client (for example via Dependency Injection).
Does that help?
Ilja Preuss wrote:This looks to me like we are talking about Abstract Factory here, not Factory Method.
James Clark wrote:You are missing the point of "not changing the client object code."
The classes of client objects which use the "factory method" do not need to be renamed, recompiled, newed or whatever.
Keep in mind that object-oriented design patterns are typically for solving significant issues with large systems. It might be hard to learn or understand if using "small" examples with only a few classes. If your implementation of Factory Method saves you time because you do not need to modify 20 to 50 classes, then this is a significant benefit.
long meng wrote:
and a little question here is where the SomeClientObject class get the factory object ?
shall i make it an instance varible, and use setter method to assign the concrete factory object to it?