Article Preview
Buy Now
| PDF: |
Object-Oriented Thinking
Improving Object Communication
Issue: 1.3 (December/January 2002)
Author: Charles Yeomans
Author Bio: Charles Yeomans is a software developer in Lexington, Kentucky.
Article Description: No description available.
Article Length (in bytes): 4,822
Starting Page Number: 36
RBD Number: 1318
Resource File(s):
1318.sit Updated: Friday, October 17, 2003 at 12:20 PM
Related Link(s): None
Known Limitations: None
Excerpt of article text...
Here's a problem recently posed on RB-NUG: you need to change the state of controls in a window depending on whether an edit field has text entered or not. Now, this is simple enough to do by adding code to the TextChange event handler of the edit field. But is this always the best way?
The purpose of event handlers is to allow you to modify the behavior of an object. Thus, for example, the TextChange event handler of an EditField allows you to modify the behavior of the EditField when its text has been changed. But telling the EditField to reach out and modify other objects can be bad behavior.
For simple projects, it's convenient, but as a window becomes complex, allowing controls to reach out to do things to other objects leads to code that is tangled and difficult to modify; changing an event handler of one control can generate a cascade of other changes.
Instead, consider a design in which objects that need to know when an EditField's text property changes can register with the EditField to be notified when this occurs. Upon notification, these controls can do as they wish.
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
