After we apply the Command pattern, we no longer need all those button subclasses to implement various click behaviors. The GUI objects delegate the work to commands. Since the command execution method doesn’t have any parameters, how would we pass the request details to the receiver? It turns out the command should be either pre-configured with this data, or capable of getting it on its own. A GUI object might have supplied the business-layer object with some parameters. You might have noticed one missing piece of the puzzle, which is the request parameters. As a bonus, now you can switch command objects linked to the sender, effectively changing the sender’s behavior at runtime.
This interface lets you use various commands with the same request sender, without coupling it to concrete classes of commands. Usually it has just a single execution method that takes no parameters. The next step is to make your commands implement the same interface. The GUI object just triggers the command, which handles all the details.Īccessing the business logic layer via a command. From now on, the GUI object doesn’t need to know what business logic object will receive the request and how it’ll be processed. Instead, you should extract all of the request details, such as the object being called, the name of the method and the list of arguments into a separate command class with a single method that triggers this request.Ĭommand objects serve as links between various GUI and business logic objects. The Command pattern suggests that GUI objects shouldn’t send these requests directly. The GUI objects may access the business logic objects directly. This process is usually described as one object sending another a request.
COMMANDQ APP ALTERNATIVE CODE
In the code it might look like this: a GUI object calls a method of a business logic object, passing it some arguments.
However, when it comes to doing something important, like calculating the trajectory of the moon or composing an annual report, the GUI layer delegates the work to the underlying layer of business logic. The GUI layer is responsible for rendering a beautiful picture on the screen, capturing any input and showing results of what the user and the app are doing. The most common example: a layer for the graphical user interface and another layer for the business logic.
COMMANDQ APP ALTERNATIVE SOFTWARE
Good software design is often based on the principle of separation of concerns, which usually results in breaking an app into layers. But then, when you implement context menus, shortcuts, and other stuff, you have to either duplicate the operation’s code in many classes or make menus dependent on buttons, which is an even worse option. In other words, having the code for copying text inside the CopyButton subclass was fine. Initially, when our app only had the toolbar, it was okay to place the implementation of various operations into the button subclasses. For example, a user could click a small “Copy” button on the toolbar, or copy something via the context menu, or just hit Ctrl+C on the keyboard. Some operations, such as copying/pasting text, would need to be invoked from multiple places. Several classes implement the same functionality.Īnd here’s the ugliest part. Put simply, your GUI code has become awkwardly dependent on the volatile code of the business logic. First, you have an enormous number of subclasses, and that would be okay if you weren’t risking breaking the code in these subclasses each time you modify the base Button class. What can go wrong?īefore long, you realize that this approach is deeply flawed. These subclasses would contain the code that would have to be executed on a button click. Where would you put the code for the various click handlers of these buttons? The simplest solution is to create tons of subclasses for each place where the button is used. While all of these buttons look similar, they’re all supposed to do different things. You created a very neat Button class that can be used for buttons on the toolbar, as well as for generic buttons in various dialogs.Īll buttons of the app are derived from the same class. Your current task is to create a toolbar with a bunch of buttons for various operations of the editor. Imagine that you’re working on a new text-editor app.
0 kommentar(er)
