 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Kristofer Skaug
Guest
|
 Posted: Fri Jul 11, 2003 10:14 pm Post subject: Event driven processing? |
 |
|
I had a discussion in another forum about the complexity of testing
event-driven software.
(<plug> BTW if you have not already done so, please come and vote for new
b.p.d.software-testing group proposal in non-tech! </plug>).
During this conversation I came to realize that I am extremely fond of using
events for propagating results from "worker" classes. IOW, processing
classes are treated as "data sinks" by the caller(s), which perform
something analogous to the sports term "no-look pass": The caller often does
not receive the actual product produced by the class as a result of his
submission of input data. Instead, dedicated logic sits elsewhere (in
another "code path") to profit from the (generically speaking) "OnOutput"
event of the class and take the products to the next level of processing (if
applicable).
Clearly this type of logic is very easy to implement in Delphi, with its
event properties (and also for C# I suppose), but for C++ programmers such a
model appears to be hard to grasp.
It was made clear to me that in fact, some developers even consciously avoid
this type of design, because it's (more) difficult to test.
My question for this forum is, is there a pattern or other known
design-strategy term that roughly covers the philosophy that I've described
above?
thank you, Kristofer
|
|
| Back to top |
|
 |
John Elrick
Guest
|
| Posted: Sun Jul 13, 2003 2:18 am Post subject: Re: Event driven processing? |
|
|
"Kristofer Skaug" <ya.ierfgnf (AT) thnxf (DOT) x> wrote
| Quote: | I had a discussion in another forum about the complexity of testing
event-driven software.
|
Which one?
SNIP
| Quote: | It was made clear to me that in fact, some developers even consciously
avoid
this type of design, because it's (more) difficult to test.
My question for this forum is, is there a pattern or other known
design-strategy term that roughly covers the philosophy that I've
described
above?
|
Mediator? That's what a Delphi form _really_ is.
John
|
|
| Back to top |
|
|
Kristofer Skaug
Guest
|
| Posted: Tue Jul 15, 2003 9:08 pm Post subject: Re: Event driven processing? |
|
|
"Ritchie Annand" wrote
| Quote: |
I think I might head over there sometime soon and do that  I'm a recent
unit-testing freak myself 
|
Hurry up! The proposal is scrolling over the "horizon" already, and the
response was not too overwhelming (those who did vote, were enthousiastic -
but too few!) ...
| Quote: | Sounds eminently multi-threadable, too.
|
Absolutely.
| Quote: | So, you basically package up data and queue it up on a queue where it
will get processed? I have that sort of logic all over my code, but I
never thought to think of what pattern it might be equivalent to.
|
That's the essence of it, but also it's not always just "buffering" but
"encapsulation", i.e. the same thread may come out the other end (through an
event) with a result, but no longer in the path of the function where the
original call was made.
| Quote: | Event properties are one way to do it, I suppose, but by no means the
only way to do things. Their major advantage is that you need not care
about the target class type, only that some object has some method
matching the signature.
|
Yes, I like this aspect.
| Quote: | Another way to do it is with interfaces:
snipped example
Using interfaces properly can get around object lifetime issues, as well,
but it can take a bit of trial, error and learning to get a handle on
interface programming in Delphi.
|
Yes, thanks for the pointer. I am still not so much into interface
programming, but I'd like to explore the advantages more.
| Quote: | I can't see how it would make it *that* much more difficult to test, it's
just slightly more work. You have to go 'out of your way' to make a
"mock" equivalent of what you're testing, something that increments a
number or records what got added to it in a list.
|
Yes. But I guess it increases the overhead of "test-first" design, i.e. you
have to expend more patience devising the test fixture, and if you're a
test-first type (which I'm not, though I find the idea charming), this may
slow you down more than you'd like in your micro-cycle of test-and-code,
test-and-code.
| Quote: | If you have threading involved, it can be a bit ornery - I've been using
TEvents and waiting on them, having the thing the thread is supposed to
cause do a SetEvent on that event, and waiting for the signal in the test
procedure (with a timeout, of course .
|
I do the same, but a bit more "naive" - I use simple global event flags
(booleans, integers) so far.
Works OK as long as the multithreaded monster is not too complex.
| Quote: | Dang, Subject-Observer comes to mind in a very, very small way. The POSA
2 book (which had a bit of a threading focus) had something called
Producer-Consumer... but I don't remember whether it would match this
pattern.
|
Producer-Comsumer sounds like a title that would sort-of fit... but I'll
Google on it and see how (if) it is defined.
thanks for the response,
Kristofer
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
