Hi Jim,

PMFJI but I find this issue very interesting. If I could use an example...

We have an app that requires us to import data from a third party fuel purchasing service. There are at least two of these services out there, each of which provides data in a different format. Our clients may use either, both or none of these services.

My approach (until you educate me differently <g>) is to use our "generic" dialog class which consists of a blank form with two buttons.... and

In the click method of the I place the code, complete with case statements, to import the fuel purchase data. Then I add another button to the form, the click method of which contains the code to produce reports about the import.

I take it from this discussion that your design would differ ??

Thanks, Ken


>Not necessarily. If the form method simply passes the message onto the behaviro objhect then you needn't make any changes to the form or its code to get different behaviors. Of course you are right that this approach requires design ahead of time and anticiapting the various scenarios that the system will encounter. That brings us to the issues relating to analysis and design and the use of use cases to describe required system behaviors.