Design notes

To stream or not to stream

It is possible to add streaming support to MStockDatabase so that objects of that type are guaranteed to be persistent. However, in certain cases streaming is unnecessary or impossible. Because the rules of inheritance require that a class obey the interface and semantics of its base classes, it is inaccurate to force all classes derived from MStockDatabase to be persistent. MStockDatabase contains protocol only. The TStockDatabase class is derived from MStockDatabase--it adds streaming capabilities. Clients that aren't persistent can hold pointers to MStockDatabase objects and those that must be persistent can hold pointers to TStockDatabase objects. In this program, all clients require it to be persistent.

It's better to be abstract

There are several places in Stock Browser where an abstract base class is defined for objects with certain responsibilities. One of those places is the Stock Server. Overriding member functions allows flexibility when retrieving stock data. For example, MStockDatabase defines several pure virtual functions. One of those, CopyStock, returns a pointer to a TStockData object. TStockServer::CopyStock returns a TLocalStockData object, which contains its own copy of all the stock data. TStockCaller::CopyStock returns a TRemoteStockData object, which doesn't contain the data--but it knows where to go to get it. The CopyStock interface only returns TStockData objects. Classes that use TStockCaller or TStockServer are unaware of this when they are handed back an object of one of the classes derived from TStockData.

It's important to note that TStockData is also an abstract class, and two classes are derived from it to implement similar, but very distinct, behavior.

RPC services versus Message Streams

Using CommonPoint Message Streams or RPC classes it is possible to develop a complex communications scheme which provides different ways of requesting information from (or adding information to) the Stock Server. The RPC services provide support for automatic call-dispatching and returning exceptions raised during a remote procedure call. While using the RPC services requires a bit more work up front, it greatly simplifies the programmatic interface. Clients such as the Stock Picker are not required to know about Message Streams or the order in which data must be streamed. Instead, they simply make a function call.


[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker