In the context of the command design pattern, is the client just the main part of your program?

Question

I'm working on my first large program, which will implement a number of design patterns I have been studying. Part of my program is a user interface with buttons and I'm using the command pattern for the commands to be tied to those buttons. My confusion is with the "client". Is it just wherever main is in your program?

Answer 1

They way I see it: there are two important conceptual entities in the command pattern and one that could have been left out:

• Most importantly the client that wants something to happen. The command objects exist because of the client. The client wants to achieve something with their help.

• The invoker, a rather stupid object that merely knows how to push simple buttons (= use methods of the command interface). Does not need to know anything about the other entities or what those commands actually do. All it has to care about is that when given a buttony thing it has to push that button. (In your case: the gui framework, that when humans press gui buttons, "pushes" the onAction() or whetever method-"button").

• The receiver. Kind of just bloating up the whole image: If a command contains a method call then, obviously there is an object that receives this method call. But there is no reason to include the reciever in the picture.

What you define as "the client" in your program is basically up to you. The thing that wanted the commands to exist. Commands work for the client.

I really don't know what exactly could be client in your case. Since you use commands as callback, maybe the receiver of those commands is also client. That's the place that wants to get informed about button presses so it can act.

Client can really be a lot of things, a simple method or a an entire thousands-of-classes abstraction layer. Maybe even entities that are not modeled as classes. Like you as the programmer.

Answer 2

Clients are presented in many design patterns, not just in Command. Here's a diagram from http://sourcemaking.com/design_patterns/command :

Often, the client is the part of the design that wants to benefit from the protected variations of the design pattern. Protected variations works like a plug-in scheme. That is, you can make changes to the open part, and the client won't be affected because it depends only directly on the closed part.

You could say in the Command Pattern that the client won't need (much) changing if you add new commands (which are like plug-ins).

Answer 3

In your scenario this is probably the case, but it is not true for command pattern as a whole. It may be another program or a network interface. What matters is that the client wants to mess with your classes and the command pattern will make sure everything is centralized