After doing a rough sketch of a high level object model, I am doing iterative TDD, and letting the other objects emerge as a refactoring of the code (as it increases in complexity). (That whole approach may be a discussion/argument for another day.)In any case, I am at the point where I am looking to refactor code blocks currently in an if-else blocks into separate objects. This is because there is another another value combination which creates new set of logical sub-branches. To be more specific, this is a trading system feature, where buy orders have different behavior than sell orders. Responses to the orders have a numeric indicator field which describes some event that occurred (e.g. fill, cancel). The combination of this numeric indicator field plus whether it is a buy or sell, require different processing buy the code.Creating a family of objects to separate the code for the unique handling each of the combinations of the 2 fields seems like a good choice at this point.  The way I would normally do this, is to create some Factory object which when called with the 2 relevant parameters (indicator, buysell), would return the correct subclass of the object. Some times I do this pattern with a map, which allows to look up a live instance (or constructor to use via reflection), and sometimes I just hard code the cases in the Factory class.So - for some reason this feels like not good design (e.g. one object which knows all the subclasses of an interface or parent object), and a bit clumsy. Is there a better pattern for solving this kind of problem?  And if this factory method approach makes sense, can anyone suggest a nicer design?
Looking for a better Factory pattern (Java)
java;design;object oriented
Your approach sounds good to me.  Philosophically, while your factory does know about every subclass, it doesn't know that it knows.  In other words, in the future subclasses might be generated elsewhere, in places your factory knows (and cares) nothing about.  At the other end, the users of these subclasses neither know nor care where they came from.  Might be from the factory, might be from somewhere else.Your bad feeling on this is that you are replacing a simple mechanism with a fancy one, and you don't (yet) really need the power you are getting.  You may indeed be wasting your time.  But if your system grows, you might have several factories, and many other objects might create these subclasses, including the subclasses themselves.  So long as your factory does not need to know about all the subclasses, and so long as your consumers don't need to know which factory, if any, they came from, your design is sound.  Everything is properly encapsulated and polymorphic.One other thing:  in Java more so than in other languages, a subclass often works better than putting a switch in the base class.  In Java I'll subclass anything if I need a slightly different behavior.  In C#, I'll go to a lot of trouble to make one class highly flexible with extra fields and extra constructor parameters.  A new Java class can be created in a small block of code with no references to it elsewhere--a local or anonymous class.  In C# the new class has to be placed well away from the only spot to reference it as anything but its base class--and it may be several levels of base--or interface.