Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Ideas for passing records back to calling form
Message
From
22/09/2015 16:41:19
Walter Meester
HoogkarspelNetherlands
 
 
To
22/09/2015 16:05:04
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 8
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01624724
Message ID:
01624949
Views:
84
Likes (1)
>>>Wow. How about doing nothing and getting the best speed? Have the called form adopt the data session of the calling form. 3 lines of code. Talk about overkill and waste.
>>>
>>
>>Hi Mike:
>>
>>He can do that, obviously, but I prefer to suggest in the line of encapsulation and separation of concerns, because having a private datasession for later changing datasessions for me is like having local variables but having a special method to read them from outer modules, this breaks the encapsulation.
>>
>>But this is my personal point of view, and every developer can use what think it's better for him/her.
>
>A cursor exists in one data session. It is encapsulated. The form has a private data session. That makes it encapsulated. The child form may drop the veil between itself and the calling form. The cursor remains encapsulated. The two forms are now encapsulated in one data session. They are encapsulated against interference from other parts of the system. That is the only important thing.
>
>The term encapsulation refers to an OOP object not exposing its properties and methods to other objects at inopportune times. If an object is instantiated within/by another object, it may certainly access the properties of the containing object. Dropping the veil in this case is no different.


Mike,

You're missing one very important point. By sharing the data session, you lose the encapsulation for the form as a unit. This is especially important if you make changes in the calling form, such as using indexes, filters (yes I've been there), etc, that have an immediate effect on the called form. Also encapsulation is especially important if you want to use the called form in several other scenarios.

Cheap speed is not the most important factor. A good design is. Switching or sharing datasessions is not always good practise. I've been in too many scenarios where I made the error for focusing on speed while I should have been focusing on encapsulation and general good design. To most users it does not matter whether a form comes up in 0.01 seconds or 0.3 seconds after the click on a button. What matters to me is that encapsulation (yes, also not sharing datasessions for that matter) makes my life easier by not periodically having weird bugs in my code that have to do with all kinds of artifacts that can and will occur.

Performance is important to any application, but it is not at the top spot. Having a well designed application that is maintainable is much more important than to optimize everything unconditionally. When performance does matter, there are always other ways of optimizing your app.

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform