build broken » Plug-In http://blog.aztec-project.org but we can fix it! Sometimes :) Fri, 11 Jun 2010 12:52:34 +0000 en hourly 1 http://wordpress.org/?v= Umsetzung des Plug-In-Patterns http://blog.aztec-project.org/2009/06/05/umsetzung-des-plug-in-patterns/ http://blog.aztec-project.org/2009/06/05/umsetzung-des-plug-in-patterns/#comments Fri, 05 Jun 2009 19:45:57 +0000 Thomas Christian http://blog.aztec-project.org/?p=5 In meinem ersten Blog-Post möchte ich euch in vereinfachter Form meine Umsetzung des Plug-In-Patterns vorstellen.
Voraussetzungen für dieses Pattern sind:

  • eine Host-Applikation die das Plug-In laden möchte
  • ein Plug-In welches es zu laden gilt
  • und die Schnittstellen Plugin und IHost

Zu allererst brauchen wir eine gemeinsame Schnittstelle, die sowohl vom Plug-In als auch vom Host (die Applikation welche das Plug-In verwenden soll) benutzt werden soll. Über diese Schnittstelle kommuniziert der Host mit dem Plug-In.
Es würde sich das Interface IPlugIn anbieten. In meinem Fall verwende ich allerdings kein Interface sondern eine abstrakte Klasse, da ich bereits Logik direkt in die Schnittstelle implementieren möchte. In meinem Fall heißt die abstrakte Klasse einfach nur Plugin. Im weiteren Verlauf werde ich zu meiner abstrakten Klasse Schnittstelle sagen.

    1 public abstract class Plugin {
    2     private IHost m_host;
    3     public Plugin(string name) {
    4         Name = name;
    5     }
    6
    7     public string Name { get; set; }
    8     public string Author { get; set; }
    9     public string Version { get; set; }
   10     public bool IsRegistered { get; private set; }
   11
   12     /// <summary>
   13     /// Setzt oder gibt die Host-Application.
   14     /// </summary>
   15     /// <value>Host-Application.</value>
   16     public IHost Host {
   17         get { return m_host; }
   18         set {
   19             if (value != null) {
   20                 if (m_host == null) {
   21                     m_host = value;
   22                     if (m_host.Register(this)) {
   23                         IsRegistered = true;
   24                     }
   25                 }
   26             } else {
   27                 if (m_host.Unregister(this)) {
   28                     m_host = value;
   29                     IsRegistered = false;
   30                 }
   31             }
   32         }
   33     }
   34 }

Ich glaube, der Aufbau der Schnittstelle Plugin sollte bis auf die Property “Host” klar sein. Wie man sieht, benötigt man bei diesem Pattern zusätzlich zur Schnittstelle Plugin noch das IHost-Interface.
Dieses Interface ist direkter Bestandteil der Schnittstelle Plugin. Nun kann man sich natürlich die Frage stellen, warum das Plug-In den Host kennen muss und somit von diesem abhängig ist.

Zum einen ist es in der Regel so, dass ein Plug-In für nur einen Host entwickelt wird und zum anderen wollte ich dem Host gewisse Richtlinien zum Registrieren und Lösen des Plug-Ins vorgeben.

Das Interface IHost sieht folgendermaßen aus:

    1 public interface IHost {
    2     bool Register(Plugin plugin);
    3     bool Unregister(Plugin plugin);
    4 }

Dieses Interface muss von der Host-Applikation implementiert werden, damit sich das Plug-In am Host registrieren kann. Im letzten Satz habe ich es schon angedeutet. Nicht der Host registriert das Plug-In bei sich, sondern das Plug-In registriert sich am Host. Durch das setzen der Property Plugin.Host wird die Methode Register oder Unregister vom Plug-In aufgerufen, welche der Host implementiert.

Eine vereinfachte Darstellung der Implementierung des IHost -Interfaces sieht folgendermaßen aus:

    1 public class HostApplication : IHost {
    2     private List<Plugin> m_pluginList;
    3
    4     //Konstruktor
    5     public HostApplication() {
    6         m_pluginList = new List<Plugin>();
    7
    8         //Lädt alle verfügbaren Plug-Ins zb. aus einem Verzeichnis
    9         List<Plugin> plugins = GetPlugins();
   10         foreach (Plugin plugin in plugins) {
   11             //ruft implizit die IHost.Register-Methode auf
   12             plugin.Host = this;
   13         }
   14     }
   15
   16     public void ShowPlugins() {
   17         foreach (Plugin plugin in m_pluginList) {
   18             //Ausgabe der Namen aller am Host registrierten Plug-Ins
   19             Console.WriteLine(plugin.Name);
   20         }
   21     }
   22
   23     public void UnloadPlugins() {
   24         foreach (Plugin plugin in m_pluginList) {
   25             //ruft implizit die IHost.Unregister-Methode auf
   26             plugin.Host = null;
   27         }
   28     }
   29
   30     #region IHost-Implementierung
   31     public bool Register(Plugin plugin) {
   32         if (!m_pluginList.Contains(plugin)) {
   33             m_pluginList.Add(plugin);
   34             return true;
   35         }
   36         return false;
   37     }
   38
   39     public bool Unregister(Plugin plugin) {
   40         if (m_pluginList.Contains(plugin)) {
   41             m_pluginList.Remove(plugin);
   42             return true;
   43         }
   44         return false;
   45     }
   46     #endregion
   47 }

Das Registrieren und Lösen der Plug-Ins könnte man nun noch in einen Plug-In-Manager auslagern, worauf ich in diesem Blog allerdings verzichten möchte.

Share

]]> http://blog.aztec-project.org/2009/06/05/umsetzung-des-plug-in-patterns/feed/ 0