And, to simplify that a bit. One could implement the strategy pattern with a CASE statement, test conditions, and instantiate the appropriate subclass.

The value in this is that you only have to determine the environment once. Then the subclass deals only with code specific to that environment. It's not necessary to keep testing the environment in every method that handles different views.

Again, this is overkill if you only need to test the environment once.

Jay

>>>If you have multiple methods which behave differently for the different views, then subclassing the class to handle the separate views would simplify code all around. You could then use an abstract factory to determine which subclass to instantiate to handle the specific view.
>>
>>Jay
>>
>>What is an abstract factory?
>>
>>Renoir
>
>An "abstract factory" is a design pattern. The concept of a design pattern was developed by a group of OO developers (the gang of 4), and explained under a book of the same name.
>
>A design pattern is an economical solution to a common programming problem. I'm still getting a handle on it. Using design patterns provides flexibility within the sometimes overly hierarchical structuring of OO.
>
>For further info on design patterns, Steve Black has lots of good stuff on his WIKI as one of the major proponents of patterns in the VFP world:
>
>http://fox.wikis.com/wc.dll?Wiki~DesignPatterns
>
>Actually, the design pattern appropriate for your use would be the "Strategy" pattern -- which determines which subclass in a class to instantiate given certain conditions.
>
>For the Strategy pattern specifically:
>http://fox.wikis.com/wc.dll?Wiki~StrategyPattern
>
>Enjoy!
>
>Jay