Re: mucking with Event Definitions to get tighter coupling to Objects ?
- From: "Bill Woodruff" <msnwsgroups@xxxxxxxxxxxxxx>
- Date: Mon, 4 Feb 2008 08:47:05 +0700
Peter Duniho wrote :
<intro : specific responses to your comments follow this generic response
.... >
.... thanks Peter for taking the time to ponder seriously this somewhat outre
thought experiment ! fyi : I have extended this one step further to address
the issue of code maintenance and clarity (I hope) by defining a static
class called "CustomEvents : I now include each Custom Event definition as a
static class within 'CustomEvents. The decision to implement the container
class and its nested inner Event classes as static was done more just to see
"if I could get away with it" rather than on any deep strategy. And I was
damn surprised it worked immediately
Next step would be for me to see if I can define a base static class that
CustomEvents would inherit from to isolate certain common features shared by
all CustomEvents and abstract the code a bit further. And then to look at
using a non-static class container, within which the contained Event
definitions could also be non-static. For me I look at this kind of
experimentation as being like seeking to understand the "standard model" in
physics by examining black holes and other variant phenomena :) It's long
range value may be nil, or may be, I hope, a more solid grounding for myself
in understanding the "standard model." And then the obvious next step is to
see if I can refactor the Events based on some common feature they share (or
focus on combining Events by just having them all pass the pointer to their
originating WinForm context, with more "work" being done in the Controller
to pull out from the passed WinForm pointer data of interest.
The "bigger picture" for me here is the context of implementing an MVC model
window manager where there is one MainForm, and an arbitrary of secondary
windows (with Parent == null) created at run-time by the end user. The
end-user will have the choice to create several kinds of secondary windows
using pre-defined WinForm templates; some of those Windows could contain
data-bound controls. So, imho, potentially, in trying to strive to have the
"Controller" robust (must listen for and handle many different types of
Events being raised as needed by the secondary windows), as well as maintain
state lists of all current Windows updated as they possibly "wink and blink
out of existence" or "pop into being," I see a potential need for some
custom events.
</intro>
2. what issues could arise from not following the standard .NET event
Sender, EventArgs parameter order structure.
PD : "The primary issue I see is the one that motivates the .NET convention:
if
you make the event delegate signature dependent on the class implementing
the event, then you cannot write a handler that is compatible with
multiple classes, generally speaking. One exception is if the event is
declared in a base class, then of course you could have a single event
handler method handle the same event for multiple derived classes."
I see your point. In this case I was thinking about a future scenario in
which derived types would inherit ... a point you raise in your response.
This is more a "gedanken," a thought experiment for self-educational
purposes (I hope for other developers also when I finish an article in which
I will use this to illustrate, by contrast, how the "standard model" is
structured and operates.
PD : "The other issue is of course adhering to existing conventions. This
is
not one I personally worry too much about, but I know that others do and I
don't fault them for it. This isn't a code-correctness issue so much as
it is a potential maintenance and multi-person team issue."
Indeed. The risks of unconventional code for maintenance and team
collaboration would be a number one "real world" consideration.
4. could this technique, by eliminating casts and lookups contribute any
real increase in speed or whatever in apps ? In other words, given you
Can use it, is it worth using ?
PD : "Not from a performance point of view, no. If your code's performance
is
bottlenecked by a cast, then it is already doing basically nothing and
should be able to do that nothing extremely quickly. :)"
Point well taken. Being an old dinosaur who comes from the Pleistocene where
every byte counted, :) I am always scanning for ways to reduce look-ups and
casts. Perhaps now that we wallow in gigabytes of ram and blazing cpu's
that's an antediliuvian habit that I can kick :)
PD : "if you're asking a question, post code that someone will actually
read, and
which includes _only_ the bare minimum required. ...There was no need to
post
all that other stuff, and the more complex the code you post, the more
likely someone will not read it, or will even ignore your entire post."
Good point ! The judgement call I made to include more elaborate code here
was based on the idea that I wanted to make it a little more than abstract
since I was discussing a variant from standard practice (and also on the
asummption that the folks here can look at more complete code quickly and
see exactly where and how the variance from the "standard model" occurs).
With hindsight, I think you are right, I could have could have cut the
included way down. It being a long, long day and night of sweating over code
is no excuse :)
thanks, Bill Woodruff
dotScience
Chiang Mai, Thailand
.
- Follow-Ups:
- References:
- mucking with Event Definitions to get tighter coupling to Objects ?
- From: Bill Woodruff
- Re: mucking with Event Definitions to get tighter coupling to Objects ?
- From: Peter Duniho
- mucking with Event Definitions to get tighter coupling to Objects ?
- Prev by Date: Re: Dependency Injection - Can It Be This Simple?
- Next by Date: Re: mucking with Event Definitions to get tighter coupling to Objects ?
- Previous by thread: Re: mucking with Event Definitions to get tighter coupling to Objects ?
- Next by thread: Re: mucking with Event Definitions to get tighter coupling to Objects ?
- Index(es):
Relevant Pages
|
