delphi – 为什么从代码调用eventhandler是不好的做法？

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设计没有按钮，菜单会发生什么？一个更好的方法是把事件处理程序的动作分解出来，使它独立于它附加的控件。有几种方法可以做到：

>一个是完全摆脱MenuItem1Click方法，并将Button1Click方法分配给MenuItem1.OnClick事件属性。对于被分配到菜单项事件的按钮而言，这是令人困惑的，所以你需要重命名事件处理程序，但是没关系，因为与VB不同，Delphi的方法名称不定义它们处理什么事件。只要签名匹配，您就可以将任何方法分配给任何事件处理程序。两个组件的OnClick事件都是TNotifyEvent类型，因此它们可以共享单个实现。命名方法，他们做什么，而不是他们属于什么。
>另一种方法是将按钮的事件处理程序代码移动到一个单独的方法中，然后从两个组件的事件处理程序调用该方法：

procedure HandleClick;
begin
  // Do something.
end;

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

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

这样，真正做的东西的代码不直接绑定到任何组件，并且让您更容易地更改这些控件，例如通过重命名或用不同的控件替换它们的自由。将代码与组件分离导致我们采用第三种方式：
>在Delphi 4中引入的TAction组件是专为您描述的情况而设计的，其中有多个UI路径用于同一个命令。 (其他语言和开发环境提供类似的概念;它不是Delphi独有的)。将事件处理代码放在TAction的OnExecute事件处理程序中，然后将该操作分配给按钮和菜单项的Action属性。

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属性，你完成了。不需要编写更多的代码，使新的控件看起来和行为像旧的。你已经写了一次代码。

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