RE: [DUG] Discussion & Donation

[Kyley Harris]

Thank. Point 1/ Fair enough Point 2/ correct . I had written that bit early on before I realized I could break it down correctly with TMethdo.code and TMethod.Data and I haven’t fully refactored it yet. I’ve removed it now. Point 3/ Because you cant do anything with a bunch of procedures. Ie it is not portable. Class functions can be overridden. You don’t need to use TNotifier.AddListener,  You could have for example add a meta class and a classvariable to the global, Var NotifierClass:TNotiferClass = TNotifer. I then use this for accessing the functions and down the track in some cases or applications you may wish to modify how it works, without effecting All the other apps by simply changing the class pointer. static procedures do not lend themselves to upgrading software without breaking old software and this is one of the most powerful uses of static classes as libraries that many people in Delphi don’t take advantage of. Point 4. I use constants, so I don’t have typos in message names (except for demos). And I use SameText, so they are not case-sensitve. I do this purely because I prefer debugging meaningful strings rather than integers. It also makes It easier when dealing with storage of types etc in human readable XML. So that’s why I do it. Many books use integers. I just don’t like it. Also. A lot of my infrastructor permits streaming of the entire message, and the data object over TCP as part of the notification. I prefer unknown apps receiving this to get a meaningful ‘CLIENT_OBJECT_UPDATED’ rather than 3 ;)   The StringList is indexed, and its very fast, I’ve tested with thousands of binds with no real time effect. The work done by listeners is the time issue. Not the lookup.     I used to have an observer and observed class system too. And it was really annoying when you had to make changes. I even wrote a plugin for the IDE to convert an object into a listener etc by inserting all the code for me. So that took the hassle out. But I prefer the decoupled method.   Thanks for the feedback.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Martin Sent: Monday, 15 May 2006 10:38 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Discussion & Donation   Well you said you wanted feedback, so I hope this isn't too picky.   1) I find the inconsistent use of variable prefixes a bit annoying. I tend to stick with F- class field A - method parameter P - pointer and no prefixes for class properties or local variables.   2) TListenerItem.FListener is redundant, since the information it contains is already held in TListenerItem.FBindMethod It could have been implemented as a function, but I don't see why it is needed. As usual, redundancy leads to complication elsewhere   eg.  if (MethodEquals(TMethod(Items[i].FBindMethod) ,TMethod(ABinder))) and (Items[i].FListener = AListener) then   the second condition is automatically satisfied by the first condition.   3) Why define a TNotifier class when all its methods are static? They could be defined as simple procedures/functions in the unit.   4) I'm not keen on the idea of passing a string parameter to identify the message type, for the simple reason that spelling mistakes can arise and you're never really sure at compile time what "messages" are being broadcast/handled. This problem can of course be ameliorated through the use of constants, but I prefer the use of an enumerated type.   Having said all that. I like the loose coupling of your solution. I have implemented the observer pattern previously with the lists maintained internally by the objects involved, so removing the need to inherit from a particular class is a great improvement. I hadn't considered that option before. Of course you do pay a miniscule performance penalty in having to find the correct list for the object. Perhaps the use of THashedstringlist could mitigate this further.   Todd.     ----- Original Message ----- From: Kyley Harris To: NZ Borland Developers Group - Delphi List Sent: Wednesday, May 10, 2006 3:36 PM Subject: [DUG] Discussion & Donation   In an attempt to create some more interesting discussion, other than talking about the crud IDE issues, I am donating some useful code for discussion, rather than for help. Feel free to keep/use the code if you want to. Be mean if you feel the need (but if your personal then watch out ;) Hopefully this may introduce a discussion where people learn something, or are able to contribute some interesting ideas/information about the topic (which is object notification and observation).   In the attached zip is a sample application showing a basic, but horrible use of the class in uNotifier.pas. TNotifer is a class I wrote a long while back which loosely follows an observer pattern for allowing one-to-many observations between an object, and a bunch of interested object.   The main difference this class has between many observer patterns is that you do not have to modify existing classes, or sub-class anything, or instantiate anything in your existing objects. The TNotifier handles all the bindings, you just need to implement one listening event on each listening object.   The sample app is a corny app that makes child forms (button click) update a memo based on changes to the memo on the main form. God help me if I ever did anything as potentially unthread safe as that in a real app.   Fun fun fun…. (I hope the app compiles. You never know with these tricky little sample apps) _______________________________________________ Delphi mailing list Delphi@ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.1/327 - Release Date: 28/04/2006

_______________________________________________
Delphi mailing list
Delphi@ns3.123.co.nz
http://ns3.123.co.nz/mailman/listinfo/delphi