为什么是从代码调用事件处理程序的坏习惯? [英] Why is it bad practice to call an eventhandler from code?

查看:180
本文介绍了为什么是从代码调用事件处理程序的坏习惯?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设您有一个菜单项和一个按钮,执行相同的任务。
为什么不好的做法是将任务的代码放入一个控件的动作事件中,然后从其他控件调用该事件?
Delphi允许这样做,vb6,但realbasic不说,你应该把代码放入一个方法,然后通过菜单和按钮

Say you have a menu item and a button that do the same task. Why is it bad practice to put the code for the task into one control's action event and then make a call to that event from the other control? Delphi allows this as does vb6 but realbasic doesn't and says you should put the code into a method that is then called by both the menu and the button

推荐答案

这是一个问题,你的程序是如何组织的。在你描述的场景中,菜单项的行为将根据按钮的定义来定义:

It's a question of how your program is organized. In the scenario you've described, the menu item's behavior will be defined in terms of the button's:

procedure TJbForm.MenuItem1Click(Sender: TObject);
begin
  // Three different ways to write this, with subtly different
  // ways to interpret it:

  Button1Click(Sender);
  // 1. "Call some other function. The name suggests it's the
  //    function that also handles button clicks."

  Button1.OnClick(Sender);
  // 2. "Call whatever method we call when the button gets clicked."
  //    (And hope the property isn't nil!)

  Button1.Click;
  // 3. "Pretend the button was clicked."
end;

这三个实现中的任何一个都可以工作,但为什么菜单项必须依赖按钮?有什么特别的按钮,它应该定义菜单项?如果一个新的UI设计没有按钮,菜单会发生什么?一个更好的方法是将事件处理程序的动作放弃,因此它独立于它附加的控件。有几种方法可以做到:

Any of those three implementations will work, but why should the menu item be so dependent on the button? What's so special about the button that it should define the menu item? If a new UI design did away with buttons, what would happen to the menu? A better way is to factor out the event handler's actions so it's independent of the controls it's attached to. There are a few ways to do that:


  1. 一个是摆脱 MenuItem1Click 方法,并将 Button1Click 方法分配给 MenuItem1.OnClick 事件属性。对于被分配给菜单项事件的按钮而命名的方法很容易混淆,因此您需要重命名事件处理程序,但是没关系,因为与VB不同,Delphi的方法名称不会定义什么事件处理。只要签名匹配,您就可以将任何方法分配给任何事件处理程序。两个组件的 OnClick 事件都是 TNotifyEvent 类型,因此它们可以共享单个实现。

  1. One is to get rid of the MenuItem1Click method altogether and assign the Button1Click method to the MenuItem1.OnClick event property. It's confusing to have methods named for buttons assigned to menu items' events, so you'll want to rename the event handler, but that's OK, because unlike VB, Delphi's method names do not define what events they handle. You can assign any method to any event handler as long as the signatures match. Both components' OnClick events are of type TNotifyEvent, so they can share a single implementation. Name methods for what they do, not what they belong to.

另一种方法是将按钮的事件处理程序代码移动到一个单独的方法,然后从两个组件的事件处理程序调用该方法:

Another way is to move the button's event-handler code into a separate method, and then call that method from both components' event handlers:

procedure HandleClick;
begin
  // Do something.
end;

procedure TJbForm.Button1Click(Sender: TObject);
begin
  HandleClick;
end;

procedure TJbForm.MenuItem1Click(Sender: TObject);
begin
  HandleClick;
end;

这样,真正做的东西的代码不直接绑定到任何组件, >让您可以更轻松地更改这些控制,例如重命名它们或用不同的控件替换它们。将代码与组件分开可导致第三种方式:

This way, the code that really does stuff isn't tied directly to either component, and that gives you the freedom to change those controls more easily, such as by renaming them, or replacing them with different controls. Separating the code from the component leads us to the third way:

TAction 组件Delphi 4,是专门为您描述的情况设计的,其中有多个UI路径同一个命令。 (其他语言和开发环境提供类似的概念;它不是Delphi独有的。)把你的事件处理代码放在 TAction ' OnExecute 事件处理程序,然后将该操作分配给按钮和菜单项的 Action 属性。

The TAction component, introduced in Delphi 4, is designed especially for the situation you've described, where there are multiple UI paths to the same command. (Other languages and development environments provide similar concepts; it's not unique to Delphi.) Put your event-handling code in the TAction's OnExecute event handler, and then assign that action to the Action property of both the button and the menu item.

procedure TJbForm.Action1Click(Sender: TObject);
begin
  // Do something
  // (Depending on how closely this event's behavior is tied to
  // manipulating the rest of the UI controls, it might make
  // sense to keep the HandleClick function I mentioned above.)
end;

想要添加另一个UI按钮吗?没问题。添加它,设置它的 Action 属性,你完成了。不需要编写更多的代码,使新的控件看起来和行为像旧的。您已经写了一次该代码。

Want to add another UI element that acts like the button? No problem. Add it, set its Action property, and you're finished. No need to write more code to make the new control look and act like the old one. You've already written that code once.

TAction 不仅仅是事件处理程序。 它可以确保您的UI控件具有统一的属性设置,包括字幕,提示,公开程度,启用度和图标。当命令在当时无效时,相应地设置操作的启用属性,任何链接的控件将自动被禁用。不需要担心通过工具栏禁用命令,但仍然通过菜单启用。您甚至可以使用操作的 OnUpdate 事件,以便操作可以根据当前条件更新自己,而不需要知道什么时候发生可能需要您设置启用

TAction goes beyond just event handlers. It lets you ensure that your UI controls have uniform property settings, including captions, hints, visibility, enabledness, and icons. When a command isn't valid at the time, set the action's Enabled property accordingly, and any linked controls will automatically get disabled. No need to worry about a command being disabled through the tool bar, but still enabled through the menu, for example. You can even use the action's OnUpdate event so that the action can update itself based on current conditions, instead of you needing to know whenever something happens that might require you to set the Enabled property right away.

这篇关于为什么是从代码调用事件处理程序的坏习惯?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆