SW Architektur und eigene AddIns

Zwecks Erweiterbarkeit sind AddIn Schnittstellen für die derzeit geplante Software (Host) im Gespräch. Da inkrementell entwickelt wird, gibt es verschiedene Meinungen für das frühzeitige Einfliessen der AddIn Struktur in das Grobkonzept.

Mittlerweile bin ich paar Tutorials durchgegangen und bin selbst der Meinung, daß sich AddIns nachträglich implementieren lassen (Interfaces only). Der Gegenpart ist eher der Meinung, daß im Falle eines nachträglichen Implementierens, das komplette Schnittstellenkonzept neu konzipiert und programmiert werden muss.

Hat jemand Erfahrung mit AddIn bzw Plug-In Programmierung und könnte bestätigen, daß diese nicht von der SW Architektur abhängig sind? Natürlich auch wenn ich falsch liegen sollte.

Erweiterungspunkte sind ein explizites Architekturmerkmal. Wenn du z.B. einen konkreten Typen in deinem Code verwendest ist diese Stelle nicht Plugin-tauglich. Aus dieser Sicht hat dein Kollege durchaus Recht.

Aber bei inkrementeller Entwicklung ist es immer eine Abwägung, ob man "potentielle" Erweiterungen in der Architektur vorsieht oder nicht. Wenn aber jetzt schon konkrete Anforderungen/Ideen bzgl. Plugins auf dem Tisch liegen, dann macht es natürlich Sinn, die notwendigen Änderungen zu berücksichtigen, auch wenn die konkrete Implementierung der Plugins später erfolgt. Zumindest lohnt sich eine Risikoabschätzung.

Erstmals Danke für die Antwort, svenson.

Wie definierst du "konkreten Typ" und dessen Untauglichkeit für Plug-In Implementierung?

Plugins zeichnen sich doch dadurch aus, dass die Funktionalität über Interfaces und nicht über Klassen angesprochen wird. Benutzt du in deinem Hauptprogramm also eine Klasse statt eines Interfaces ist dieser Code per se nicht Plugin-tauglich.

Wenn Funktionalität zur Laufzeit eingeschossen wird, z.B. über Plugins, Dependency Injection o.ä. dann sind Interfaces ein Muss.

Wenn die Plugins UIs anbieten ist dafür auch entsprechender Schmalz vorzusehen. Auch das Thema Serialisierung ist u.U. kritisch.

Erstmals Danke für die Antwort, svenson.

Wie definierst du "konkreten Typ" und dessen Untauglichkeit für Plug-In Implementierung?

Ein konkreten Typ wäre z.B. eine Klasse statt eines Interfaces.

Ich denke er meinte das es gut wäre vieles über Schnittstellen also Interfaces und intern so viel wie Möglich über Factory abzubilden, damit unabhängig von Typen bleibst.

[Edit] Da war er selber schneller,)