C#, container class design pattern?

Question

I delved into C# but came across a problem that I seem unable to solve:

I designed a financial back test and trading engine and as part of that I like to implement a "Strategy Container". This strategy container should serve two purposes. (1) hold instances of different strategies that perform mathematical computations, and (2) provide accessors in order to pass new tick data into the strategy instances and to receive certain information back from the strategy instances.

The different strategies I mentioned above should be unique classes which, however, derive from a base class. I want to perform completely different operations within those strategies thus I thought designing them as separate classes that derive from one base class would be feasible. One complication is that I need multiple instances of each strategy class that is contained in the Strategy Container. Each strategy class also holds a list of stock symbols and each symbol should get its on strategy instance.

Another important point of the Strategy container is that it can create, instantiate, and later also invoke each strategy instance.

I wanted to ask some of you what kind of ideas you have how I could go about designing and implementing this:

• what would be the overall best design pattern?
• as described if I create different classes for each strategy then I would obviously end up with different types as well, how could I hold all those in one container/collection within the Strategy Container?
• How can I either through reflection or other means create, instantiate, and invoke methods of each single strategy instance without knowing how many I would end up with. I do know the names and types of the strategies and I know the names of the stock symbols.
• I simply want to supply which strategies I want to hook up (I supply the strategy names = class names?) and for each strategy a list of stock symbols. The Strategy Container would create instances for each symbol in each strategy of the strategy type that the list was supplied for and would subsequently invoke a "RunStrategy(Quote quote)" method that feeds new quotes into each instance so that computations can be performed.
• One goal would be to keep the interface of each strategy class as clean as possible, with most of the standard (repetitive) functionality being implemented in the derived-from base class.

I do not ask for full source code but for ideas what you think how I should design this thing and how I could accomplish each of above points. This is something for myself and wont turn into any commercial product. I am very comfortable with writing code that implements the mathematical bits and pieces but I am less familiar with design patterns and system architecture.

Edit: Graymatter, I played a bit around and seems you provided exactly what I was looking for. Thanks a lot.

class Program
{
    static void Main(string[] args)
    {
        List<IStrategy> container = new List<IStrategy>();

        container.Add(new StrategyOne());

        container[0].AddValue(50);

        Console.ReadLine();
    }




}

public interface IStrategy
{
    void AddValue(int value);  
}


public class StrategyOne : StrategyBase
{
    public override void Calculates()
    {
        Console.WriteLine("This is my value: " + myValue);
    }

}

public class StrategyBase : IStrategy
{
    protected int myValue;

    public void AddValue(int value)
    {
        Console.WriteLine("Run Strategy in Base");

        myValue = value;

        Calculates();
    }

    public virtual void Calculates()
    {

    }  
}

Solution 1

You should really look at using interfaces for this type of system. The interface is your contract with the strategy and you can any number of different implementations for the interface. Your container would then contain interfaces.

Something like:

public interface IStrategy
{
  void RunStrategy(Quote quote);
}

Then your implementations would be something like this:

public class StrategyOne : IStrategy
{
  void RunStrategy(Quote quote)
  {
  }
}

The container could be:

List<IStrategy> container = new List<IStrategy>();

Solution 2

Well, design should emerge out of the requirement analysis/crunching. I would not just decide to use this or that pattern and then try to see how it fits to the domain.

derive from a base class

Again this must be warranted by the common functionality that is to be done by the base class, otherwise, an interface is all you need. Strategy pattern is defined by a common interface where all strategies act upon a common data structure.

So my suggestion is to abandon any pre-judgement about the design and fully focus on the requirements and the modelling of your domain. Good design will just emerge out of this.