Object Access Methods and Encapsulation
All objects should be accessed in one of the following ways:
1. Sending Messages to Self
Send|Get|Set Message [of self]
This sends the message to itself (the sending and receiving object are the same). The of self is not necessary; the compiler will handle this for you. Most messages are sent within an object, and you will use this method most often.
2. Delegating Messages
Delegate Send|Get|Set Message
This sends the message to the object's parent.
3. Sending Messages to Another Object
Send|Get|Set Message of object_name
This finds an object_id for the access expression and sends a message to it. When required, the access method is delegated.
4. Using a Handle for Multiple Messages
Move object_name to hoId
Send|Get|Set Message of hoId
If you are sending multiple messages to an object inside a function or procedure, you can save time by evaluating the object_id once and sending all messages to this ID (hoId). This saves the runtime from having to continually re-evaluate the same expression. The speed difference is minimal. If a message is sent to an object only once in a function or procedure, use the previous access method. If multiple messages are sent to an object, use this method.
Example:
Procedure doSomething
Handle hoID
Move oMyObj to hoID
Send request_save of hoID
Send request_Clear of hoID
Send Activate of hoID
End_Procedure
You can use these access rules as a means of confirming that your program is properly encapsulated. If you cannot access an object using one of these methods, you should not be accessing that object.
Accessing Grandchild Objects
The question that usually arises at this point is, "How do I send a message to a grandchild object?" The answer is, "Normally, you don't!" (The exception is discussed in the next paragraph.) If you need to access a grandchild object, you should send a message to the child object, which should then send a message to its child. If you insist on breaking this rule, you may do so with an expression (e.g., Send Message of (oGrandChildName(oChildName))). Treat this kind of code the same way you would a goto statement. Place several comments around it stating that you know this is wrong, apologizing for it, and promising to come back and correct it. If you are maintaining someone else's code and you encounter this kind of code, proceed cautiously.
Exception to the Rule
There is a very useful exception to this rule. When building visual applications, visual objects are often nested inside other visual container objects. When this type of object nesting occurs, it is done to make a panel or dialog look right and is not done for purposes of encapsulation. When these visual objects need to communicate with each other, access can be complicated. Object Neighborhoods are used to remove this complication.