Zitat von
Elvis:
Für non-visuelle macht es mehr Sinn von vorn herein auch innerhalb der Exe auf einer Interface-basierte
API aufzubauen.
Zum Beispiel sowas (aus den Fingern gesaugt)
Delphi-Quellcode:
var
menu : IMenuProvider;
menuItem : IMenuItem;
begin
menu := Services.GetService(IMenuProvider) as IMenuProvider;
menuItem := menu['Edit'].AddItem('Copy');
menuItem.Caption := '&Copy';
menuItem.Click := @CopyClickHandler;
end;
Auf die Art hat man genau die Art
Dog-Fooding, die nötig ist damit Plugins genügend Möglichkeiten haben um wirklich sinnvoll zu sein. Denn wenn die
API, die auch die Plugins nutzen, nicht mächtig genug ist, merkst du das schon während du deine HauptApp schreibst.
Nicht alle mögen diese Art der Programmierung, wie sie schon in der Delphi-
IDE genutzt wird. Und wenn man bei einem Rein-Delphi-Programm bleiben will, dann braucht man das auch nicht.
Als ich die MAF Components gebaut habe, wollte ich diese Art der Programmierung extra vermeiden und den Leuten die Möglichkeit geben, ihren gewohnten Delphi-Stil beizubehalten. Bei mir können sich Plugins in Funktionen "reinhängen", neue Funktionen zur Verfügung stellen oder auch vorhandene "umleiten", weil die alten buggy sind oder weil man etwas für einen Kunden ändern musste, der das
Standart-Verhalten nicht mochte.
Und anstelle von der obigen Version, wo jedes Plugin sich am Menü selbst anmeldet, gehe ich im Normalfall die anderen Weg herum, wo es nur eine zentrale Stelle gibt, wo Menü-Punkte angemeldet werden, die Plugins liefern sozusagen nur die Daten, mit denen sie angemeldet werden wollen. Das macht es einfacher, etwas zu ändern, da man eben nur eine Stelle hat, wo etwas passiert. So kann man zum Bsp. vom Delphi-
Standart TMainMenu auf ein Menu von 3rd-party Komponenten umstellen, weil es vielelicht besser aussieht oder die Funktionen hat, die man braucht für sein Programm.