Ich bin ein Softwareentwickler, der bereit ist, seine Fähigkeiten im Bereich Software-Design zu verbessern. Ich denke, Software sollte nicht nur funktionieren, sondern auch ein solides und elegantes Design haben, um wiederverwendbar und für spätere Zwecke umfangreich zu sein.
Jetzt bin ich auf der Suche nach Hilfe, um bewährte Verfahren für bestimmte Probleme zu finden. Eigentlich versuche ich herauszufinden, wie man eine Software entwirft, die über Plug-Ins erweiterbar ist.
Die Fragen, die ich habe, sind die folgenden:
- Sollten Plug-Ins in der Lage sein, auf die Funktionen des jeweils anderen zuzugreifen? Dies würde Abhängigkeiten bringen, denke ich.
- Was sollte die Hauptanwendung den Plug-Ins bieten, wenn ich beispielsweise eine Multimedia-Software entwickeln möchte, die Videos und Musik wiedergibt, aber später Funktionen über Plug-Ins hinzufügen kann, die beispielsweise den Videostatus lesen können ( Zeit, bps, ...) und anzeigen. Würde dies bedeuten, dass der Player selbst Teil des Hauptprogramms sein und Plug-Ins Dienste anbieten müsste, um solche Informationen zu erhalten, oder würde es eine Möglichkeit geben, den Player auch als Plug-In zu entwickeln, aber auf irgendeine Weise die Möglichkeit zu bieten zu anderen Plug-Ins, um damit zu interagieren?
Wie Sie sehen, dienen meine Fragen hauptsächlich Lernzwecken, da ich mich bemühe, meine Fähigkeiten in der Softwareentwicklung zu verbessern.
Ich hoffe, hier Hilfe zu finden und mich zu entschuldigen, wenn etwas mit meiner Frage nicht stimmt.
Antworten:
So gut wie jede Software, die im Laufe der Zeit von mehreren Mitwirkenden, die nicht eng miteinander verbunden oder koordiniert sind, "erweitert" werden soll, kann von einer Plug-In- Architektur profitieren . Häufige Beispiele sind Betriebssysteme, CAD- und GIS-Tools, Zeichen- und Bildbearbeitungswerkzeuge, Texteditoren und Textverarbeitungsprogramme, IDEs, Webbrowser, Webinhaltsverwaltungssysteme sowie Programmiersprachen und Frameworks. Plugins sind die Hauptstütze erweiterbarer Systeme.
Plug-in-Architekturen verwenden normalerweise die Ententypisierung . Der Architekt definiert einen gemeinsamen Satz von Methoden (zB
open,close,play,stop,seek, etc.), die jede Plugin implementiert dann (entweder vollständig oder teilweise ). Einige Methoden sind obligatorisch, während andere optional oder nur in bestimmten Fällen nützlich sein können.Wenn das Hauptprogramm zum ersten Mal ausgeführt wird, überprüft es einen oder mehrere "Plugin-Bereiche" (z. B. bekannte
./pluginsVerzeichnisse) auf das Vorhandensein von Plugins. Die gefundenen werden in das Programm geladen.Oft müssen Plugins zum Zeitpunkt der Ausführung des Hauptprogramms vorhanden sein. Der Unix-Kernel und der Apache-Webserver arbeiten normalerweise auf diese Weise. Sie müssen neu gestartet werden, um neue Plugins zu "sehen" und zu verwenden. Plugins können jedoch dynamischer sein; Hier sucht das Hauptprogramm regelmäßig nach neu hinzugefügten oder geänderten Plugins (z. B. durch Vergleichen eines gespeicherten
plugins-last-loadedZeitstempels mit dem "zuletzt geänderten" Zeitstempel für ein Plugins-Verzeichnis). Das Hauptprogramm würde dann Plugins (neu) laden - entweder alle im einfachen / naiven Fall oder nur die neuen / geänderten, wenn es ausgefeilter ist.Es gibt oft eine "Registrierungs" -Anforderung, wobei jedes Plugin nicht nur Code ist, sondern auch einige Metadaten enthält , die kommunizieren, wie das Plugin in das Ganze integriert wird. Beispielsweise kann ein Musik-Player-Plugin erforderlich sein, um anzugeben, welche Art von Dateien abgespielt werden kann, auf welchen Prozessorarchitekturen es ausgeführt werden kann, welche Ressourcen benötigt werden (z. B. wie viel Speicher zugewiesen werden muss). und andere Attribute, die das Hauptprogramm benötigt, um zu entscheiden, welches Plugin zum Abspielen welcher Datei verwendet werden soll.
Die Mechanismen für die Registrierung, das Laden und die Interaktion von Plugins mit dem Hauptprogramm sind sehr sprach- und Framework-spezifisch. Da viel "Orchestrierung" stattfindet, wobei einige Funktionen vom Hauptprogramm und einige von seinen Plugins (von denen es möglicherweise einige gibt) ausgeführt werden, erfordert das Einrichten eines Programms für Erweiterbarkeit Sorgfalt und Überlegung sowie eine Architekturansicht des Programms als "ein System" und nicht als "ein einziges Stück Code".
Die meisten Großprojekte haben bereits ein Plugin-Framework ausgewählt oder ein eigenes entworfen. Es gibt auch eine Reihe allgemeiner Plugin-Frameworks, die die Umwandlung Ihres Programms in ein erweiterbares System vereinfachen sollen.
(Antwort auf Frage 1) Während Plug-Ins die Funktionen des anderen nutzen können, tun sie dies normalerweise über die vom Architekten festgelegten vordefinierten Methoden / APIs. Die Verwendung einer solchen "Ententypisierung" hilft, Super-Interdependenzen zu vermeiden, und bedeutet, dass nicht unbedingt klar ist, ob eine bestimmte Funktion durch "Kern" -Code oder ein Plugin bereitgestellt wird. In der Tat implementieren viele Entwickler nach der Einführung einer Plug-In-Strategie sogar "Kern" -Funktionen als Plugins - nur solche, die mit dem Hauptprogramm geliefert werden. Obwohl es nicht ideal ist, Spaghetti-Plugins zu haben, ist es nicht ungewöhnlich, dass einige Plug-Ins die Existenz anderer Plug-Ins erfordern.
(Antwort auf Frage 2) Als Architekt bieten Sie Plugins hauptsächlich eine Architektur an - z. B. eine Reihe von Methoden, mit denen sie eingerichtet, registriert und aufgerufen werden, sowie ein Design und eine Reihe von Anforderungen, in denen die Plugins ausgeführt werden . Das Hauptprogramm stellt während der Ausführung normalerweise viele, wenn nicht alle seiner internen Datenstrukturen und -methoden Plugins zur Verfügung. Dies ist offensichtlich ein Sicherheitsrisiko. Eine Reihe von Sandbox- Techniken kann (und wird zunehmend verwendet) verwendet werden, aber meistens handelt es sich bei Plugins um "vertrauenswürdigen" Code, der so funktioniert, als ob sie Teil des Hauptprogramms wären.
Zur weiteren Lektüre:
quelle
interfaceund keine reine (untypisierte) Ententypisierung sind.