 |
|
| Computers Forum Index » Computer - Object » Can I have Interface & Inheritance together for same... |
|
Page 2 of 2 Goto page Previous 1, 2 |
|
| Author |
Message |
| H. S. Lahman... |
 Posted: Mon May 18, 2009 8:55 pm |
|
|
|
Guest
|
Responding to Zabroski...
Quote: Why don't you mention callbacks in your list of physical coupling?
Actually, callbacks are much worse than physical coupling, because
they create logical coupling messes that cannot be undone.
Remember, I am a translationist so I only think of collaboration in
terms of <announcement> messages passed at the OOA/D level. B-)
A callback is just one of many implementation mechanisms that could
implement navigation of a relationship at OOP time. Basically one has:
1 R1 sends message to 1
[A] ------------------------------ [B]
at the OOA/D class model level. In the end A is just sending a message
to B via navigating the R1 relationship. Invoking the callback simply
initiates a collaboration by sending the message to whoever owns the
callback on the other end of R1, just like any other message in OOA/D.
The R1 relationship was instantiated when the B callback was registered
with A. IOW, the OOA/D is going to look exactly the same whether R1 is
instantiated with a callback or a simple reference pointer.
Now at the 3GL level message and method are not separated so the message
is <usually> the method signature and the navigation mechanism is a
procedure call. But that method has to be owned by the right object so
one instantiates the relationship to connect to the right receiver. That
is exactly what goes on in almost any OO collaboration message passing
at the 3GL level. The only difference is the way message addressing
(relationship instantiation) is implemented, by registering the
callback. So I don't see a logical coupling problem that is worse than
any other collaboration.
As far as physical coupling is concerned, I don't see a problem unique
to callbacks either because relationship implementation, instantiation,
and navigation is intentionally designed to be orthogonal to class
semantics. (Full code generators for OOA models treat relationships very
much like AOP aspects.) The 3GLs may muck things up with their marriage
of message and method in type systems, but that is a potential problem
for any sort of collaboration.
Bottom line: I think you are going to have to put more words around why
you thing callbacks are especially evil.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.lahman at (no spam) verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html |
|
|
| Back to top |
|
|
|
| John \"Z-Bo\" Zabroski... |
| Posted: Mon Jun 22, 2009 2:37 am |
|
|
|
Guest
|
On May 18, 12:55 pm, "H. S. Lahman" <h.lah... at (no spam) verizon.net> wrote:
Quote: Responding to Zabroski...
Why don't you mention callbacks in your list of physical coupling?
Actually, callbacks are much worse than physical coupling, because
they create logical coupling messes that cannot be undone.
Remember, I am a translationist so I only think of collaboration in
terms of <announcement> messages passed at the OOA/D level. B-)
I think this answers my question.
Quote: Bottom line: I think you are going to have to put more words around why
you thing callbacks are especially evil.
I think callbacks are moreso a problem when you actually do need to
know when you will be called back upon. This can often mean requiring
signal be more than just a signal (more than just an announcement that
a state has changed). The programmer may need to send a value to know
whether the value is still valid once the signal is acted upon.
Therefore, at the third generation language level, I think that
callbacks are a real problem.
I also think many programmers use callbacks in a way that ultimately
leads to God Objects that centralize their behavior into an object
with a lot of hooks. I'm aware of techniques for using callbacks
safely, such as those discussed by Clemens Szyperski, but I simply do
not like the idea of a callback. It just seems wrong, and like an
unnecessary constraint on how to do something. It feels like a very
weird way to encode a von Neumann moving head tape reader.
I don't particularly like my description above, but perhaps you can
improve upon it. |
|
|
| Back to top |
|
|
|
| H. S. Lahman... |
| Posted: Mon Jun 22, 2009 6:20 pm |
|
|
|
Guest
|
Responding to Zabroski...
Quote: Bottom line: I think you are going to have to put more words around why
you thing callbacks are especially evil.
I think callbacks are moreso a problem when you actually do need to
know when you will be called back upon. This can often mean requiring
signal be more than just a signal (more than just an announcement that
a state has changed). The programmer may need to send a value to know
whether the value is still valid once the signal is acted upon.
If I understand this correctly we have something like Module A does
something to change the state of the solution. Module B needs to respond
to that state change. Module B could provide a callback that module A
invokes. So far, so good. Module B is just defining the announcement
message that Module A needs to send. [In most cases where callbacks are
used (e.g., subsystem to subsystem), I would prefer better decoupling by
providing some sort of wrapper or Observer-like registration, but that's
for other reasons.]
But what Module B does may affect state variables that Module A
subsequently uses, so Module A needs to know what Module B did. One
mechanism for achieving that is for the callback to return a value to
inform Module A about any changes.
That I definitely do not like because, as you point out, the callback is
more than a simple announcement signal. Aside from its own intrinsic
response it is also providing a synchronization function. And the return
value is creating a dependency in Module A's implementation on what
Module B's response actually does. That is definitely a no-no for
behavior communications at the OOA/D level.
But I see this as a design issue. One needs to separate the concerns of
flow of control (Module B's response to Module A's state change) from
the concerns of synchronization. IOW, one needs separate messages.
Module B does its thing in response to Module A's original announcement.
In the course of doing that it may or may not change the state of the
solution in a manner that requires Module A's response. If it changes
the solution state, Module B sends a separate announcement message back
to Module A. (Conceivably both messages could be callbacks!)
One way this is more robust is because Module A's response to Module B's
change is no longer tied to the flow of control sequence. IOW, Module B
can now modify the state variable(s) independently of whether the
original callback was actually invoked and Module A will still correctly
respond to that change. Thus the synchronization of state changes in
both Module A and Module B can be managed independently of any specific
*sequences* of operations in either module.
Quote: I also think many programmers use callbacks in a way that ultimately
leads to God Objects that centralize their behavior into an object
with a lot of hooks. I'm aware of techniques for using callbacks
safely, such as those discussed by Clemens Szyperski, but I simply do
not like the idea of a callback. It just seems wrong, and like an
unnecessary constraint on how to do something. It feels like a very
weird way to encode a von Neumann moving head tape reader.
Per my argument above, I think this is also a design issue. God objects
are also a no-no and it doesn't matter whether the "hooks" are
callbacks, state machine events, or other messages.
Now having said all this, I would agree that callbacks are overused. The
primary advantage of callbacks lies in providing hooks into modules when
one cannot know until at least link time what the communication syntax
is. The callback mechanism is convenient because it allows functionality
to be accessed generically (e.g., linking w/o compilation).
A classic example are the On_Event callbacks that the RAD IDEs define.
The application developer provides the code in a procedure with that
name and the IDE handles the registration when the developer creates a
procedure with that signature. It is a very simple and elegant way to
extend the functionality of the RAD IDE. But in the end the RAD IDE just
sends that predefined message when the On_Event condition is raised.
But I would argue that in all the situations I can think of where using
callbacks is very convenient, one needs a some sort of registration
mechanism. (In the RAD IDE the developer's callback is registered by
substituting its entry point for the IDE's default no-op entry point in
a jump table.) That is, one needs to use callbacks when the caller
cannot know a priori what the message must be (i.e., one needs to get
around the 3GL type system and namespace constraints). If one doesn't
need to do that, then it would be simpler and probably more robust to
use interacting state machines to define handshaking protocols.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.lahman at (no spam) verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sat Nov 28, 2009 2:12 am
|
|