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
相关问题
- Is there a Delphi 5 component that can handle .png
- Is there a way to install Delphi 2010 on Windows 2
- Is TWebBrowser dependant on IE version?
- iOS objective-c object: When to use release and wh
- DBGrid - How to set an individual background color
相关文章
- Best way to implement MVVM bindings (View <-> V
- Python relative import with more than two dots
- Windows EventLog: How fast are operations with it?
- How to force Delphi compiler to display all hints
- Coloring cell background on firemonkey stringgrid
- Bind a char to an enum type
- Reading (with Filesystem.FileGet) VB6 record file
- HelpInsight documentation in Delphi 2007
Because you should separate internal logic to some other function and call this function...
This is a more elegant solution and is much easier to maintain.
Suppose at some point you decide that the menu item no longer makes sense, and you want to get rid of the menu item. If you just have one other control pointing to the menu item's event handler, that might not be a big problem, you can just copy the code into the button's event handler. But if you have several different ways the code can be invoked, you'll have to do a lot of changing.
Personally I like the way Qt handles this. There is a QAction class with it's own event handler that can be hooked, and then the QAction is associated with any UI elements that need to perform that task.
Another big reason is for testability. When event handling code is buried in the UI, the only way to test this is via either manual testing or automated testing that is heavily tied to the UI. (e.g. Open menu A, Click button B). Any change in the UI naturally can then break dozens of tests.
If the code is refactored into a module that deals exclusively with the job it needs to perform, then testing become a whole lot easier.
Separation of concerns. A private event for a class should be encapsulated within that class and not called from external classes. This makes your project easier to change down the road if you have strong interfaces between objects and minimize the occurences of multiple entry points.
Suppose at some time you decided that the menu should do something slightly differently. Perhaps this new change only happens under some specific circumstances. You forget about the button, but now you have changed its behaviour as well.
On the other hand if you call a function, you are less likely to change what it does, since you (or the next guy) knows that this will have bad consequences.
Why is it bad practice? Because it is much easier to reuse code when it is not embedded into UI controls.
Why can't you do it in REALbasic? I doubt there's any technical reason; it's likely just a design decision they made. It certainly does enforce better coding practices.