> From my perspective, I think you're right on the mark. One thing I'll > add is that using a "Strategy factory method" will not easily fit the > purposes here either because using multiple Strategies is actually > involved in processing a document. I suppose a single Strategy could > encapsulate multiple sub-processes though. For example, I have two > discrete processes involved to complete document processing: 1. > Process/transform the received message. 2. Submit the transformed > message to specific processor out of many potential processors. >
If you have multiple strategies involved, you might look at the Adapter or Fa�ade pattern to see if you can simplify them down to a single object that invokes multiple, small steps to perform the work. You can still use a factory to create them. Recognize that factories can be implemented in a variety of ways - you could associate a map of your keys (in memory or disk/database) to Assembly/Types and then dynamically create the type, use reflection by triggering off a custom attribute with each type, or a plain-old switch statement. It just depends on the level of coupling that you are comfortable with or need based on your project. Chain of responsibility is another option for creating them, although if the strategy objects are completely different, can be added or removed dynamically, or the relationship between the algorithm and the key isn't fixed then the factory is generally a better option as it removes the coupling between all the strategies themselves. Best Regards, Mark Smith DevelopMentor =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
