Imagine you’ll have always a button labeled “Continue” in the same position in your app’s GUI.
Would you rather make a single button instance that takes different actions depending on the current state?
private State currentState = State.Step1;
private ContinueButton_Click()
{
switch(currentState)
{
case State.Step1:
DoThis();
currentState = State.Step2;
break;
case State.Step2:
DoThat();
break;
}
}
Or would you rather have something like this?
public Form()
{
this.ContinueStep2Button.Visible = false;
}
private ContinueStep1Button_Click()
{
DoThis();
this.ContinueStep1Button.Visible = false;
this.ContinueStep2Button.Visible = true;
}
private ContinueStep2Button_Click()
{
DoThat();
}
5
My proposal is to have a single button, but instead of the switch statement, have a listener interface which is implemented by classes that processes the clicks, and on every click, change the listener that is now responsible.
class myForm extends Form {
ClickListener listener1 = new ClickListener_page1(this);
private Continuebutton1_Click() {
listener1.click();
}
}
class ClickListener_page1 implements ClickListener {
Form form;
public ClickListener_page1(Form form) {
this.form = form;
}
public click() {
page++;
// here goes all the stuff to process page 1
form.listener1 = new ClickListener_page2(form);
}
}
class ClickListener_page2 implements ClickListener {
Form form;
public ClickListener_page2(Form form) {
this.form = form;
}
public click() {
page++;
// here goes all the stuff to process page 2
form.listener1 = new ClickListener_page2(form);
}
}
4
I’ve stumbled upon this in the past. I had a button changing its label (from Next to Finish) but otherwise keeping its position. I used two distinct buttons.
In general, I prefer using different physical buttons and playing with their visibility, instead of using a single button and changing its behavior. The rationale is simply that the former is easier to understand and maintain. Imagine expanding your problem to multiple buttons which can have different behaviors in different contexts and having to change the listeners on those buttons when the context changes. This can push you into an artificial pattern of having to save references to, or re-instantiate your button listeners, or devise artificial click handling schemes.
That said, in some cases the logical model dictates the use of an action with contextual results, such as “Save”. If that action is prominently displayed in a global area, such as a header, such as it is always visible, then I believe it makes sense for that action to remain shared. Of course, in such a case, the action delegates to the screen currently displayed in order to achieve the action, so, again, logic dictates your outcome.
If there is a different logical action, different listeners, little relationship between the actions, these are strong indicators of the need to use different buttons and adjust their visibility based on context.
If, on the other hand, the actions have a common pattern (as supported by the button label – probably your case), then use a single button and investigate the possibility of delegation to the current context to achieve the action.
[It’s interesting to think about, in the latter case, dealing with common pattern actions where some require more user input (actions that should have an ellipsis (…)), and some do not, in which case it becomes tricky to use the same button.]
1
If the operations are the same just on a different context (e.g. all are next or all are appply or all are send) you should use the same button.
If the operations are different (e.g. volume up vs. channel up or adjust equalizer) do not use the same button or position.