nicht angemeldet
Hi JP,
Plug-ins sind ein Software Design Pattern. Wobei für einen bestimmten Plug-In-Typen, welcher eine bestimmte Funktion unterstützen, erweitern soll, z.b. ein X.509 Zertifikat o.ä. laden, ein Interface mit einer zu implementierenden Methode (oder/und auch Properties) geschrieben wird, welches öffentlich ist.
Um es mit C# auszudrücken:
public interface ICertificatePlugin
{
string Fingerprint { get; }
void LoadCertificate();
}
Du schreibst dann deine Implementierung der jeweiligen Properties und Methoden, kompilierst das ganze, packst es in einen Ordner, wo die Hauptanwendung das Kompilat (.dll o.ä.) laden kann. z.b.
public class X509CertLoader: ICertificatePlugIn
{
private string fingerprint = string.empty;
// c'tor
public X509CertLoader() { }
// implementing the property defined by the interface
public string Fingerprint
{
get { return this.fingerprint; }
}
// implementierung der eigentlich geforderten Methode
public void LoadCertificate
{
// ... dein Programmcode
}
}
Wenn jetzt die Hauptanwendung dein Plug-In ausführen möchte, wird sie (wenn nicht schon beim Start getan) deine Komponente laden und als Objekt instanzieren. Anhand der Angabge, welches Interface du implementierst kann sich die Hauptanwendung darauf verlassen, dass es eine bestimmte Methode/Property in deinem Objekt aufrufen kann. Dies tut es dann auch.
Der ganze Vorgang wird von meist einem "Manager"/"Singleton" Pattern begleitet, welches dafür verantwortlich ist:
- zu schauen welche Plug-ins da sind
- diese zu laden und zu instanziieren
- die Interface-Methode eines bestimmten instanziierten Objektes aufzurufen
Wenn du da genauer drüber bescheid wissen möchtest, schau dir am besten folgende Literatur an: http://www.amazon.de/exec/obidos/ASIN/0201633612/ref=ed_of_dp_1/302-6419383-1160809
HTH, Ciao, Frank
P.S. ich übernehme keine Garantie für die Vollständigkeit und fachliche Unfehlbarkeit meiner Angaben :-)