actions i GUI

Der er fordele og ulemper ved begge dele, men i bund og grund er det en smagssag.

Det er overkill at implemterer en listener for hver aktion, og man bruger derfor ofte inner classes til at håndtere dette. Hvis man ikke
er forsigtig med det, bliver handlingskoden spredt ud over det hele. Det kan blive meget grimt.

Personligt plejer jeg at bruge actionPerformed, og uddelegerer til andre metoder ved hjælp af simple if-sætninger. Dette giver en overskuelig
kode

Jeg er enig med lbhansen langt hen af vejen, men jeg kan nu også godt anbefale brugen af anonyme klasser, f.eks.

myComponent.addActionListener(new ActionListener(){
  public void actionPerformed(ActionEvent e)
  {
    // Et eller andet
  }
}
);

Jeg bruger denne fremgangsmåde hvis den pågældende action listener kun skal bruges et sted i koden. Så slipper man også få at skulle navngive en masse klasser samt at tilføjelsen af listeneren og implementationen af den er samme sted (langt fra altid ønskeligt men i mange tilfælde syntes jeg det er OK).

lbhansen: >> overkill at implementere en listener,..man bruger inner classes.

En inner class er nu engang som regel en implementering af et listener interface, så ...?

faceorbit: >>

Spørgsmål om stil, men jeg ville typisk gøre følgende.

En action betyder ofte invokering af en eller evt. flere handlingsmønstre (usecases) som skal udføres, og typisk har man en eller flere controlklasser til at håndtere dette. En action skal derfor mappes ned til den control klasse, som skal udføre tingene. Om man så genanvender en actionlistener, gør sig vel gældende om den skal delegere flere hændelser ned til samme kontrolklasse.

Klasser af forskellig art kan implementere et interface, og derved stiller de en funktionalitet til rådighed. Synligheden af den kan også diskuteres. Hvis jeg vil modtage actions, skal jeg kunne optræde som ActionListener. Hvis jeg implementerer det, gør jeg det public, så alle kan se mig som en ActionListener, og rent faktisk invokere actionPerformed(ActionEvent) uden at der nødvendigvis er tale om en action fra en komponent, jeg havde forventet.

På grund af det, vil jeg altid have indre klasser til at modtage events fra kendte sources, så jeg slipper for et public interface. Suns swing folk har ikke lige tænkt så langt, så eksempelvis til definitionen af metoden JTable.valueChange(ListSelectionEvent) + andre steder, står der følgende i javadoc:

Application code will not use these methods explicitly, they are used internally by JTable.


public class MyGui { // Don\'t extend JFrame
  private JFrame f;
 
  ActionListener action = new ActionListener() {
    public void actionPerformed(ActionEvent e) {
      doAction(); // Delegate to MyGui class.
    }
  };

  public MyGui {
  JPanel p = new JPanel();
  JButton b = new JButton(\"Dav\");
  b.addActionListener(action); 
  f.setContentPane(p);
  f.setSize(500,500);
  f.setVisible(true);
  }

  // Protected, så derived classes may improve the scenario without
  // Having to speculate in listeners etc.
  protected void doAction() {
    ModelFramework.identifyModel().performUsecase();
  }
}

Og nu er det i øvrigt sådan, at der skal ligge logik i gui klasserne. Hvordan skal man ellers kunne vise de rigtige oplysninger på de rigtige tidspunkter. Det folk mener (når de fejlagtigt siger ovenstående) er at dit modellag i selv selv skal være robust, dvs. kunne genanvendes selv om der kommer et andet GUI, om dine handlingsbestemte usecases kan fyres af få steder fra, og du har velspecifierede interfaces til din model. De andre kommentarer er rent amatørargumenter for folk, der ikke har fået hår på endnu.

Jeg vil bøje mig i støvet for Logical han har det med at vide hvad han snakker om:)

logical>> Der er jo en hvis robusthed over dit svar så :)