The magic pushbutton anti-pattern is very common in graphical programming environments . In this scenario, the programmer draws the user interface first and then writes the business logic in the automatically created methods.

Problems with this anti-pattern are:

• The code behind the Pushbuttons grows unmanageably
• Changing the user interface (or adding an alternate interface) is difficult
• Testing the code is difficult

Bad Example (Borland Delphi)

procedure TForm1.Button1Click(Sender: TObject);
var
  reg:TRegistry;
begin
  reg:=TRegistry.Create;
  try
    reg.RootKey:=HKey_Current_User;
    if reg.OpenKey('\Software\MyCompany',true) then
    begin
      reg.WriteString('Filename',edit1.text);
    end;
  finally
    reg.Free;
  end;
end;

Good Example (Borland Delphi)

A better way to do this is to put the business logic (in this example storing the filename to the registry) into a class.

type
 TPreferences = class
 private
   FFilename: string;
   procedure SetFilename(const Value: string);
 public
   property Filename:string read FFilename write SetFilename;
   procedure Load;
   procedure Save;
 end;

and call this class Save method from the Click handler:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Preferences.Save;
end;

procedure TForm1.Edit1Change(Sender: TObject);
begin
  Preferences.Filename:=edit1.text;
end;