Ich wollte eine Infrastruktur schaffen, die Aktionen ausführt als Reaktion auf beliebige Trigger-Ereignisse. Die Ergebnisse der Gedanken, die ich mir dazu gemacht habe, werden hier dargestellt.

Im Prinzip sind die Gedanken, die ich mir gemacht habe einfach zusammenzufassen: Man wähle eine Architektur, die der Swing-Action beim Erzeugen eine Instanz übergibt, die das Interface Configuration implementiert.

Werden die Actions in eine andere Klasse hinein kombiniert, muss diese Klasse das Interface implementieren. Ansonsten ist es natürlich auch möglich, dass eine eigene Konfigurations-Klasse geschaffen wird, die das Interface implementiert. Dadurch wird die Kette zu einer aus drei Gliedern: die Instanz, die die Action nutzen möchte, übergibt eine Instanz der Konfigurationsklasse an die Action. Sie kann das Verhalten der Action dann über Änderungen an der Konfigurationsinstanz beeinflussen.

Das Interface selbst ist zunächst einmal nur ein Marker-Interface:

public interface Configuration
{
	
}

Dazu habe ich eine generische Basisklasse geschrieben, die wie folgt aussieht:

public abstract class ConfigurableActionBase<T extends Configuration> extends javax.swing.AbstractAction
{
	private final T conf;

	public ConfigurableActionBase(T conf, String name)
	{
		super(name);
		this.conf = conf;
	}

	public ConfigurableActionBase(T conf, String name, Icon icon)
	{
		super(name, icon);
		this.conf = conf;
	}

	public ConfigurableActionBase(T conf)
	{
		super();
		this.conf=conf;
	}
	
	public T getConfiguration()
	{
		return conf;
	}
}

Damit hat man in abgeleiteten Klassen einen typsicheren Zugriff auf die Konfiguration erreicht. Eine abgeleitete Action-Klasse könnte dann zum Beispiel so aussehen:

public class ConfigurableAction extends ConfigurableActionBase<ConfigurableAction.Configuration>
{
	public ConfigurableAction(Configuration conf)
	{
		super(conf);
	}
	public ConfigurableAction()
	{
		this(new ConfImpl());
	}
	public interface Configuration extends de.elbosso.util.pattern.command.Configuration
	{
		boolean isEnabled();
	}
	public void actionPerformed(java.awt.event.ActionEvent evt)
	{
		System.out.println(getConfiguration().isEnabled()?"enabled":"disabled");
	}
}

Man beachte das Inner-Interface, das das Marker-Interface erweitert. Der zweite Konstruktor dient der Bequemlichkeit: Wenn die Konfiguration über eine eigene Implementationsklasse erfolgt, muss die Klasse, die die Action benutzen möchte, diese Instanz nicht implizit erzeugen, sondern kann einfach den diesen Konstruktor benutzen, durch den eine Default-Implementations-Instanz erstellt wird, auf die wiederum mit der entsprechenden Getter-Methode zugegriffen werden kann. Im Beispiel könnte diese Default-Implementation wie folgt aussehen:

public class ConfImpl implements ConfigurableAction.Configuration
{
	private boolean enabled;

	public boolean isEnabled()
	{
		return enabled;
	}

	public void setEnabled(boolean enabled)
	{
		boolean old=isEnabled();
		this.enabled = enabled;
	}	
}

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )