Laden...

SW Architektur und eigene AddIns

Erstellt von Sera vor 15 Jahren Letzter Beitrag vor 15 Jahren 818 Views
S
Sera Themenstarter:in
285 Beiträge seit 2005
vor 15 Jahren
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.

S
8.746 Beiträge seit 2005
vor 15 Jahren

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.

S
Sera Themenstarter:in
285 Beiträge seit 2005
vor 15 Jahren

Erstmals Danke für die Antwort, svenson.

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

S
8.746 Beiträge seit 2005
vor 15 Jahren

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.

915 Beiträge seit 2006
vor 15 Jahren

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,)

Wie vernichtet stand Andreas unter den flammenden Augen seiner Kunden.
Ihm war's, als stünde des Schicksals dunkle Wetterwolke über seinem Haupte X(