My question is similar to (but not exactly the same as) this question. This question was also helpful but it is less similar to my current question than the previous question that I linked to.I have a framework that runs automated testing. Basically, an XML script has data on which methods to call against our API; our engine runs the specified methods with reflection.Due to how the logs are generated, sometimes we want to replace certain method calls with another one. (There's not really any way around that). A factory knows which methods those are based on an XML file that contains the mapping.// Originally we called this a Command pattern but it may be more accurate to call it a Strategy// See if we're supposed to replace this method call with something elsebool wereAnyCommandsRun = await ExecuteCommandsIfThereAreAny(interfaceName, methodName);// If we're NOT supposed to replace this method call, go ahead and execute itif (!wereAnyCommandsRun){   // Do the method call   // ...}We do the XML mapping like this:<map method=CaptureDomain interface=IFrameworkInterface command=ApplyXsltCommand/>Right now Commands (probably more accurately Strategies) are completely standard - they implement an interface with an Execute() method.Now I need to add parameters to this. I don't know in advance which parameters they will need, so I'm trying to come up with something that wouldn't be completely hideous and fragile. My main requirements are that I don't want the design to become overly complicated; also, the primary point of this is to make my engine as future-proof as possible, so I want to make sure that it doesn't require modification if I add or refactor a method or a new requirement comes in (meaning that the Command and its caller have to be loosely coupled).A few ideas I had and rejected:Accept a params array and use reflection to decide whether the caller passed in values of the correct type. I don't like this though because it dramatically increases the coupling between the command, and the whole point of the mechanism is to reduce the coupling.Create parameter objects for each possible type. This, too, would create a lot of coupling.Parameterized factoriesSome ideas I'm seriously considering:Have a Context object like one of the answers in the question I linked to suggested. If I'm reading the question I linked to correctly, the advantages here would be that the caller wouldn't have to know anything about command in advance. There could be a performance hit if I end up capturing too much information about the caller, but performance isn't a major consideration here.I have a MethodInfo object and parameter info for the method I'm replacing - maybe add this as a third item in the Factory's mapping. The first problem I see here is similar to the downside of the previous solution: the fact that a parameter is necessary for the method being called doesn't imply that it's also necessary for the Command. Also, my Commands may be called by several different methods, so it's important that there be no coupling at all between them (so it's more complicated than just if you see this parameter list, use that command). Could this lead to too much coupling?Try to implement some kind of a Visitor pattern instead of the Strategy pattern. However, I'm a little hazy on how that would actually work to tell the truth. Would this just add needless complexity, or would it actually be a legitimate solution here?I'm hoping that this isn't too broad or opinion-based (please let me know if so and I'll edit - I'm definitely not trying to ask a gimme teh codez type question), but does anyone see a problem with these solutions?
How to parameterize Commands without the caller knowing anything about the Command ahead of time
c#;design;design patterns
Well, you could use dynamic and ExpandoObject._parameterNames =>  Name of parameter_data => Data to be passed private dynamic Create(string[] data)        {            dynamic expando = new ExpandoObject();            for (var i = 0; i < _parameterNames.Length; i++)            {                ((IDictionary<string, object>) expando).Add(_parameterNames[i], data[i]);            }            return expando;        }This will give you a very flexible means to pass parameter(s) and data to your 'reflector' to add all the parameters to the method that is being invoked via reflection.  I would keep parameters in order to preserve sanity.