Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Practical limit of Properties on goApp
Message
 
To
09/03/2000 09:24:14
Cindy Winegarden
Duke University Medical Center
Durham, North Carolina, United States
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00343639
Message ID:
00343736
Views:
21
Hi Cindy,
sounds like your fishing for some food for thought here, maybe I can help. There are 2 anti-patterns that come to mind here that sort of describe an almighty goApp object like your describing here.

The first is called "The Blob" meaning you got a whole big bunch of stuff in one place. The Blob can be an awful thing to decipher by the next programmer to come along, and sometimes it can rise up in the middle of the night and eat you alive when an unusual 'exception' occurs without forethought. Saving grace for your situation though is The Blob is typically a whole mess of 'responsibilities' in one place... IOW method code heavy objects as opposed to property heavy. And since you load goApp from a table, sounds like you got an easier means of managing the blob than if everything was hard coded.

The other that comes to mind is "The Golden Hammer". This one is where you take one tried & true technique or concept and apply it over & over & over and before you know it the whole darn app functions the same way. Golden Hammer can get almost hypnotic, you suddenly realize that somewhere along the line you stopped looking for the best answer and just mass produced an easy answer. Kind of sounds like this is what is happening now that your considering adding report info into goApp.

The way I determine what goes into goApp is this - the 1st letter - "g" = global. I only add attributes to goApp that are global in nature meaning multiple components (or even forms) need the same value; OR a value that needs to cross a lot of data sessions is another good one; values tied to a user that have a global effect on most everything; OR application level service type methods, etc.

Anything else that I really dont need in a global respect I either A) try to build into a business object or event/process object (this is Codebook thing, I can explain if you want) OR B) if I absolutely need easy access to it then I hang an task specific manager type object off of goApp as an aggregate or bridge... just like Larry described. HTH.
Roxanne M. Seibert
Independent Consultant, VFP MCP

Code Monkey Like Fritos
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform