[DUG] Discussion & Donation

Mon May 15 11:20:18 NZST 2006

To add to this topic which is really the theory of software development
techniques. 

( how you design code and write your code as a professional programmer;
and components whose sole purpose is supporting infrastructure for
making the actual user needed stuff work (Patterns) )

Imagine if, as a pro programmer/app designer. Not one line of your code
was allowed to be submitted into the main code branch of the "real" app
until it had been peer reviewed by someone else.

If it wasn't documented or written in a way your peer understands, you'd
keep cracking at it. And imagine the peer was randomized (which is
heading down the though path of extreme programming).

I think its interesting to consider how much higher you think the
quality of your code would be if you felt this was the case about every
line of code you wrote. Its no different than if an architect handed his
designs for a house to the builder and it was all freehand, except that
in software the code would get used anyway, and debugged later.

cheers

________________________________

From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
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 <mailto:kyley at harrissoftware.com>  

	To: NZ Borland Developers Group - Delphi List
<mailto:delphi at ns3.123.co.nz>  

	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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns3.123.co.nz/pipermail/delphi/attachments/20060515/ffc50c7e/attachment-0001.html