Events Call Methods

Possibly the most inflexible sort of software occurs when GUI objects are raft with code responding to events. See for example TooMuchGuiCode.

Here's a simple RuleOfThumb to observe when coding GUI objects: events always call methods.

Putting event code in Gui object event procedures is terrible practice. Putting event code in Gui object method procedures is a little better. Putting event code in a method of a handler object is better.

If you're into HookOperations, consider the following RuleOfThumb as a matched set:

events always call methods,
events are pre-hooked, and
methods are post-hooked.

-- StevenBlack

Yes! Yes! YES!

I've been saying this to anyone who will listen for what seems like ages. I've seen more people get into trouble by "visual programming" (meaning hooking events to events and events to attributes and attributes to attributes and whatnot) in VisualAge than just about any other trick. The problem is that I see this same thing happening in the VisualAge for Java world just as often as in the VisualAge for Smalltalk world.

I always tell my students to do this. Visual Programming ala VisualAge is a cute trick, and it makes for slick demos and rapid easy prototyping, but it's not scalable or maintainable, as far as I've seen.

-- KyleBrown

<<story follows>>

When I was on a panel at SmalltalkSolutions back in '96 with AlanKnight and RebeccaWirfsBrock we were taking questions on "What it takes to be a Smalltalk guru". At one point, a gent stood up and asked "So What does it take to become a VisualProgramming guru?" A hush descended over the panel as we each glanced nervously at each other. Finally, I hesitantly took the mike and said "I'm probably going to get slammed for this, but honestly, I don't believe in Visual Programming and don't ever recommend it." At that point it was like a dam burst -- Alan and Rebecca both chimed in with VisualProgrammingHorrorStories? from their clients, a theme that the audience took up after we finished. At least it showed I'm not alone in my feelings...

I agree completely and have seen similar reactions to my asserting this in public. VisualProgramming is AllSomeFolksKnow, and hearing this is quite unsettling for some.

Kyle you'll surely get a real gas out of the August 1998 issue of HarpersMagazine which has a great opening article on the numbing trend of wizards and code generators and whatnot. Moreover the very next short article is a nice slam against Microsoft. The whole issue is great and I hope you can still get your hands on it.

-- StevenBlack

Here's a good rule of thumb:

Everything you can do to the GraphicalUserInterface's forms, you can also do thru a test rig on the LogicLayer or RepresentationLayer.
That TestRig? and its business layer can compile without using any identifiers from your GuiToolkit.
So anything you can do to a form, you can also do inside a ProgrammerTest, addressing the BusinessLayer? directly.

-- ThePhlIpLayer

I always thought this was the way people did it until I heard people complaining about the integration of struts and similar frameworks into their applications. The ideas of layering and domain objects must be learned I guess.

I'd say ItDepends. I'd like to explore specific scenarios rather than say "doing X is always bad".