Using the strategy pattern you can do something like this(I hope I understood the problem):
1. Obviously you have a logic executed on all types of reports - the one that loads a report, invokes it(build results or something), present the results(supply the data required by the different views you have) - well it sounds like a controller.
The controller does one and the same thing with all reports by managing their life-cycle. It can do this by making all reports implement a specific life-cycle interface(invoke, buildResults and so forth)
2. The controller loads a report depending on the user selection(type of report and the data it needs) using a Factory object that hides how the different reports are created.
The factory will produce report of the correct type using a specific method or using a specific object that knows how to produce the desired report if it is too complicated.
3. The concrete implementations of report interface will differ by their input data and what they do with it. Because of the is-a relationship inheritance is a choice but I think it is better if you use composition.
So I guess in order to solve you problem you engage the factory and strategy patterns(controller is who uses the different types report building logic).
I hope that I understood the problem properly and that my idea helps.
Last edited by NewUniverse; 02-06-2009 at 03:19 AM.
There is no fear in the true love!