I’d like to write a helper class where I can stash routine operations that I want to do on every backtest.

E.g., I'm always going to want to stash the stock symbol, the test start-end dates, the account cash, etc. I want to do them early in my program, make it easy to go back and change them when re-running the test, and I need storage for them. So helper class that stores them off would be a win.

My original thought was to derive from QCAlgorithm, create a Helper class with properties/methods there, and then derive from the Helper and call Initialize in the Helper-derivative. The compiler is fine with this.

But: the backtest engine says,

"Backtest Error: Could not create instance of QCAlgorithm class. Ensure there is one class inheriting from QCAlgorithm and it overrides Initialize()”

It's worth asking: is there a security reason why we can't derive from QCAlgorithm, or was (understandable) a simple way to implement Lean?

And if the designers let us do so: how would the engine know which QCAlgorithm-derivative to instantiate? Technically there are 2: my helper class, and the class derived from it.

1. the engine could look for the QCAlgorithm-derivative that calls Initialize (but what if the Helper needs to do same?)

2. The engine could look for the QCAlgorithm-derivative that has a specific attribute on it (a common means of adding to the metadata in .NET classes). It'd be easy for the engine to scan the assembly, find all the classes with a custom attribute (e.g., [BackTest]) on it, generate an error if other than one, and continue if just one.

But both of these imply changes to the BackTest engine.

In the meantime: I could sidestep the issue, instead re-design my helper to be instantiated internally by the QCAlgorithm-derivative. It lacks elegance but it would let me solve the problem. Advantage: I can do this myself, without requesting a change to the engine.

Backtest team: any thoughts on the suggestion above, to let us create multiple QCAlgorithm-derivatives in a single backtest program?