Re: Intimate relations between two objects
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Wed, 03 May 2006 18:46:30 GMT
Responding to Ram...
A hardware device taking low-level commands might be
encapsulated within an object »o«, used as in, for example:
a = o.read();
o.write( 2 );
Another type of device might be encapsulated in another
object »p«.
There might might be a low-level copy operation between
the devices. To properly call that low-level operation one
needs to know private data of both objects »o« and »p«.
The goal is to wrap that low-level copy operation into a
method of an object or a class or something object-oriented.
In Englisch language the copy operation would be written as:
»copy from o to p«
What is the best place (object, class, ...) for this
operation (method)?
My answer is basically the same as Daniel T.'s, but let's back up a bit and talk about what [o] and [p] are. If they are essentially device drivers whose mission is to manage low level stuff like register read/modify/write, then that sort of machination needs to be thoroughly hidden. If the copy requires that sort of low level operation, then I see no alternative to o::copy(p) and p::copy(o).
However, I think it is far more likely that the copy really involves moving some data from one to another. In that case each driver should have a getter/setter to extract/accept the data and some third party decides when that should happen. The getters/setters implement the low level stuff. That third party then just invokes the extractor getter from one and passes the data packet to the setter for the other. So put those copy operations in whoever understands the context driving the copy.
At yet another level, one can eliminate the middleman if the drivers collaborate directly with one another. Then one only needs to trigger the collaboration. So somebody sends [o] a message, "it's time". Then [o] responds by sending [p] a message, "here's some data" whose data packet that has information from [o]. Finally, [p] accepts that message, interprets the data packet, and updates its internals. This is just a variation on the above where the third party does not have to arbitrate the copy collaboration.
By simplifying the third party role, I think one would have a more robust solution. IOW, one should not think in terms of "copy" as a compound operation (read one, write the other) on two objects that some middleman must understand. It would be better to just let one object collaborate on a peer-to-peer basis to accomplish the copy.
It can not be an operation of o, because it also needs access
to private data of p. And it can not be an operation of p,
because it needs private information of o.
Then the private data isn't private at the problem solution level, is it? B-)
Note that with the getter/setter approach, nobody needs to understand the semantics of the data except the two drivers. IOW, it could just be a data packet handle that is transparent to whoever initiates the copy. In addition, each driver can map the data packet to its own internals. All they need to share is a mapping of data packet elements.
However, I think that is somewhat unrealistic. I would argue that one cannot communicate with a driver while hiding register operations without providing some <public> data semantics in the driver interface. A copy from one device to another is an external path that must go through the driver interfaces if the drivers are to abstract unique problem space entities. IOW, whatever is being copied probably isn't private at the level of abstraction of the copy operation; only its mapping to the device internals is private.
I believe that this is a common (well-known) problem in
object-oriented programming. Does it have a name?
Are there established patterns to cope with it?
Others have mentioned double dispatch, but I think that would be overkill. The hardware entities are independent so there must be a collaboration somewhere between them (best) or with some other middleman object (probably not so good). Either way one just has a simple data transfer interface that decouples the implementations.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
.
- Prev by Date: Re: Searching OO Associations with RDBMS Persistence Models
- Next by Date: Re: Do orthogonal state machines know about each other?
- Previous by thread: Re: Intimate relations between two objects
- Next by thread: Re: Interdependency of Types
- Index(es):
Relevant Pages
|
