Re: A numerical methods viewpoint on OO/FP/Relational
Date: Mon, 23 Jul 2001 19:43:28 GMT
Message-ID: <3B5C8054.A0FA3829_at_worldnet.att.net>
Responding to Campbell...
> > To see why this is nasty, look at a few typical OO applications' methods
> > that call other methods to invoke other behaviors (other than simple
> > attribute accesses). If all those method calls could be moved to the
> > end of the calling method after all of its own processing is completed
> > without breaking it, then the method is not context dependent. The
> > calls would simply be announcements that the caller's processing was
> > done.
> > But if those behaviors can't be moved without breaking the
> > method, the calling method's execution is dependent on external context,
> > which breaks encapsulation.
>
> What do you mean by "context" here, the state of the system or somthing else
> ?. I'm trying to reconcile this statement with my distributed object service
> user/service provider POV: a method needs somthing doing to continue (i.e.
> non-movable operation as you describe) so it asks the object broker for
> something that can satisfy its requirement and then makes the invocation.
> What dangerous dependency am I creating by doing this ?, does this make me a
> glorified fortran programmer :-/ ? .
The context is depending upon some other, external behavior. Specifically, if a method has something like
x = some_other_method() // not a simple getter y = x
The assignment to y can't be made until the other behavior is executed. So the method is explicitly dependent upon that external behavior being executed at a particular time.
With regard to your POV problem, I would probably handle that with state machines. One action would send an event to the object broker requesting the information. The object broker's response would be an event carrying the necessary data. That event would transition to a state with an appropriate action to respond to the event with the invocation. [This is routine for us translationists because we always do behavior in state machines anyway. B-)]
In anticipation of your pointing out that the object broker has a linked-in, synchronous interface that isn't event-driven, the answer lies in the way one encapsulates modules. I would regard an object broker as a distinct subject matter that should be isolated from the rest of application by an interface because that enforces modularity. The application events would go to/from that interface. The interface would have the smarts to make the synchronous broker call and generate an event with the response data.
There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman
hsl_at_pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Received on Mon Jul 23 2001 - 21:43:28 CEST