Ramifications

[Previous] [Next]

Passing or returning an object by value results in the following consequences:

• Prevents state changes to the original object The recipient process can freely manipulate its copy of the object without impacting the original object's state.
• Localizes object services, avoiding the performance overhead of cross-process object invocation Because Visual Basic objects are synonymous with COM objects and COM objects are always passed by reference, the same holds true for Visual Basic. A major benefit of COM is location transparency. This means that the object reference can be pointing either to an object in a client process's address space or to a remote object located in the address space of another process running on the same workstation or across the network. The client remains oblivious to the object's location and continues to request object services as if the object were local to its address space. However, when the object being referenced is out of the client process's address space, requests and responses must be marshaled to and from the remote process. The overhead of such activity is tremendously higher than referencing an object within the same address space. (See Chapter 3, "COM Threading Models," and the books listed in the bibliography for a more in-depth coverage of COM.) Using the Object By Value design pattern to pass an object by value allows the remote recipient process to benefit from the services offered by an object without incurring the performance overhead cost of marshaling across process boundaries.



Figure 6-1. Passing an object by value from sender to receiver.

• Supports sharing of object copies between systems using different types of objects A key participant of the Object By Value design pattern is the ObjectTransformer class. It would not be too difficult to envision using a Conduit mechanism (such as COM or MSMQ) that is supported by dissimilar object systems to transport a data stream. Once the data stream is accepted by the recipient process, a native object transformer could produce a copy of the original object by correctly implementing the object conversion specification you, as the designer, set forth. For example, a Visual Basic object transformer could convert a Visual Basic object to a data stream, and a Pascal object transformer could convert the stream into a Pascal object copy of the original Visual Basic object.
• Encapsulates the internal state of an object Because the data stream is a byte array, you are not forced to explicitly expose the state of an object by deprivatizing that object. The persistable object contains the inherent functionality for updating its state from a byte array.
• No compile-time type checking Because the data stream is a byte array, there is no type checking at compile time. Therefore the potential for sending a byte array of invalid data to a recipient process is possible, wasting valuable processing cycles.
• Passing an object by value is not a language feature Although not terribly difficult to implement, significant programmer intervention and cooperation is required to adhere to the specification defined for implementation of the Object By Value design pattern.