After reading a lot of theories about the separation of interfaces and codes, I wonder how you understand the command/action pattern? I also have such a question here. Generally speaking, when you mention the command/action mode in dlephi, the first thing you think of is a series of action controls such as TActionList, TActionManager. However, it seems that the design method of the delphi control or the event call method is the design method of the delphi control. It is designed in the command/action mode. In other words, there is no need to deliberately pursue the command/action mode, but it is enough to pay attention to the general encoding.
As far as I understand it, take TButton's OnClick event.
Generally speaking, if we want to define this event, just double-click the control and then write code, for example:
PRocedure TForm1.Button1Click(Sender: TObject);
Begin
...;
end;
Some people may think that the coupling between the code and the interface is more serious because this function is actually mixed with the interface. If you modify the interface in the future, it will be very troublesome.
But I don't think so, let's take the following example:
If you want to use another button2 (or a menuitem or another command event) to implement this function, I can just make the OnClick event of button2 point to Button1Click. And when modifying, just maintain the Button1Click code?
Or, secondly, when I initialize button2 (because button2 can be created dynamically), just make button2.OnClick := Button1Click, why do I have to implement this so-called TAction?
Let’s talk about the control of the interface. Using the TAction object can perform some simple operations on the interface object, but in general, I can also complete the same work by calling the sender parameter of the function, for example, I want to make all calls The space of button1Click disappears and I can do this:
If Sender is TControl then
TControl(Sender).Visible := false;
This is no different from calling TAction.Visible.