Welches Design pattern am besten nehmen

fluxy

Hallo, ich habe mal eine ganz simple Frage:

Ich habe 2 Plugins und will nun vom einen Plugin die Methode des zweiten Plugins ausführen. Allerdings sollen die Plugins nix voneinander wissen. Managen tut die Plugins in Pluginmanager. Welches design pattern passt da am besten?

otze

mach dochn einfaches interface design...
die objekte eines plugins werden jeweils durch ein interface im programm repräsentiert, und wenn ein objekt von plugin a ein objekt von plugin b brauch, kriegt es stattdessen ein interface welches auf das entsprechende objekt zeigt.
am besten geht das denk ich mal über factory classes...

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

fluxy

Hallo

nein die Plugins untereinander sollen voneinander nicht kennen. Also sie haben zwar alle Ihr eigenes Interface, allerdings dürfen die Interfaces oder die Plugins nicht in Beziehung voneinander stehen. Ich dachte das command pattern hört sich ganz gut an, weiss aber nicht ob das den kern der sache trifft. Alle Kommunikation muss über den manager laufen.... Nur er kennt alle Interfaces....

fluxy

könnt ihr vielleicht einfach mal ein paar gute links zum Thema Design Pattern posten? Ich wäre an Tutorials und ähnlichem sehr interessiert...

CarstenJ

Hallo,

du zeigst ja bisher nicht gerade sehr viel Eigeninitiative.

http://home.earthlink.net/~huston2/dp/patterns.html

Diese Seite war nach 0.13 Sekunden gefunden, lt Google.

Helium

ja, boost::function ist dein Freund. Vielleicht willst du aber stattdessen auch was mit boost::signals machen. Nur so ne Idee.

Prof84

http://home.earthlink.net/~huston2/dp/mediator.html

otze

fluxy schrieb:

nein die Plugins untereinander sollen voneinander nicht kennen. Also sie haben zwar alle Ihr eigenes Interface, allerdings dürfen die Interfaces oder die Plugins nicht in Beziehung voneinander stehen. Ich dachte das command pattern hört sich ganz gut an, weiss aber nicht ob das den kern der sache trifft. Alle Kommunikation muss über den manager laufen.... Nur er kennt alle Interfaces....

da werden sich die programmierer des plugins aber freuen, wenn sie merken, dass sie absolut im leeren raum schweben.
ich glaub ich hab dir früher shconmal gesagt, dass dein programm selber die interfaces anbieten muss, und sich die plugins dann auf diese interfaces ausrichten müssen, ansonsten hat der programmierer nämlich schlechte karten...sehr schlechte.

maximal gingen dann noch funktoren,aber selbst dann muss der programmierer noch "raten". ein absolutes unabhängig sein kann und sollte es nicht geben, wenn eine klasse methoden aus der andren klasse aufrufen muss.

sagt man dem programmierer aber: dein plugin kann alles machen, nur soll es hinterher mit diesen interfaces über diese funktion(factory class) anzusprechen sein, dann hat der programmierer gleich viel mehr spaß an der sache, und deine dokumentation wird gleich viel kleiner. nebenbei kannst du auch viel effektivieren code für deinen plugin manager schreiben.

naja, is aber nur meine meinung, man sollte es sich und den leuten die plugins zum programm schreiben müssen, so einfach wie möglich machen, und wenn man die möglichkeit hat,in der programmstruktur interfaces benutzen zu können, dann sollte man es tun,denn dann hat man für sich und das plugin die garantie, dass sie gut zusammen passen.

fluxy

Mal klartext....

Die Hauptanwendung darf die Plugins gar nicht selbst anbieten, weil sie sonst von Dll's und Loaderroutinen wissen müsste. Das ganze muss ein Manager übernhemen. Die Hauptanwendung sieht zur zeit bei mir in etwa so aus:

#include <iostream>
#include <XComManager.h>
#include <log.h>

using namespace std;

#pragma comment (lib, "XComManager.lib")
#pragma comment (lib, "log.lib")

class Engine : public XGuiMessageSystem
{
	public:
		/* Konstruktoren und Destruktoren */
		Engine (void);

		/* eigene methoden */
		void CreateSurface (void);
		void getExecuteDirectory (char* argv, char* ident, char* directory);
		void initLogfile (char* path);

		/* Eventmethoden */
		virtual int Event_MouseClicked (int x, int y);
		virtual int Event_Clicked (int widget);
		virtual int Event_KeyPressed (int key);

		char* plog;
	private:
		XComGuiBase* ptr_surface;
		XGuiPrefences wpref;
		XComManager* ptr_manager;
		LOG* log;

	protected:
};

Engine::Engine (void)
{

	/* Fenster beschreiben */
	memset (&wpref, 0, sizeof (XGuiPrefences));
	wpref.width = 600;
	wpref.height = 400;
	wpref.posx = 10;
	wpref.posy = 10;
	wpref.ptr_name = "X Example";
	wpref.ptr_register = "test";

	ptr_surface			= (XComGuiBase*)NULL;
	ptr_manager			= (XComManager*)NULL;

	plog = new char [200];

}

void Engine::CreateSurface (void)
{
	ptr_manager = new XComManager (&wpref, strcpy ((char*)plog, (char*)"\\log"));
	int nplg = ptr_manager->registerPlugin (PLG_GUI, &ptr_surface, this);
	ptr_manager->GetPlugin (nPlg, ptr_surface);
	ptr_surface->xCreate (&wpref, 0);
	ptr_surface->showConsole(false);
	ptr_surface->addButton (20,20, 100, 20, 1, "start dialog");
	ptr_surface->addButton (100,100, 100, 20, 2, "testbu");
	ptr_surface->xMain (&wpref);

}

int main (int argc, char** argv)
{
	Engine* engine = new Engine ();

	engine->getExecuteDirectory (argv[0], PATH_WIN, engine->plog);
	engine->initLogfile (engine->plog);
	engine->CreateSurface ();
	return 0;
}

int Engine::Event_MouseClicked (int x, int y)
{
	printf ("\tTest\n");
	ptr_surface->InfoBox ("Event_MouseClicked", "Nachrichtendienst");

	return 0;
}

int Engine::Event_KeyPressed (int key)
{
	ptr_surface->setKey (key, true);
	char* buffer = new char [20];
	sprintf (buffer, "%c",  key);

	if (key == VK_F2)
		//ptr_render_device->Init (hWindow,&hWindow, 1,0,0,NULL);
	if (key == VK_ESCAPE)
		exit (1);
	return 0;
}

int Engine::Event_Clicked (int widget)
{
	switch (widget)
	{
		case 1:
			//ptr_render_device->Init (hWindow,&hWindow, 1,0,0,NULL);
			break;
		case 2:
			ptr_surface->InfoBox ("Event_Clicked -> Button 2", "MAC Nachrichtendienst");
			break;
		default:
			ptr_surface->InfoBox ("Event_Clicked", "ist da noch was ?!");
			break;
	}

	return 0;
}

Kurze Erklärung: Die Anwendung initialisiert eine Managerinstanz, mit der Plugins verwaltet werden können. Jetzt hat der Manager mehrere Aufgaben. Die wichtigste Aufgabe ist erstmal ein Plugin zu registrieren, also den Pointer mit der Dll zu initalisieren und ihn dann in eine map zu speichern. Die Methode speichert das Plugin dann unter einem beliebigen Index in der Map und gibt den an das Hauptprogramm zurück, damit dieses jederzeit auf die Plugininstanz zugreifen kann. Dies passiert natürlich über die Methode GetPlugin die seinerseits wieder den Keyindex erwartet und die Instanz zurückgibt. So muss die Anwendung mit jedem Plugin umgehen.

Es ist unbedingt notwendig, dass alles über den Manager läuft, da sonst die Anwendung an Kompatibilität verliert. Der Manager ist z.B. auf verschiedenen Plattformen verfügbar, sodass der Code auch in Linux kompiliert werden könnte. Falls im Code jetzt keine syntaktische Fehler drin sind, nicht dran stören, ich habe das unwichtige rausgenommen und nicht überprüft obs jetzt so stimmt.

Mein Problem ist jetzt nochmals folgendes: Ich will jetzt eine Möglichkeit haben, dass ein Plugin den Manager anweisen kann, direkt eine Methode eines anderen Plugins auszuführen. Ich könnte zwar das der Anwendung sagen, aber das finde ich doof.

Beispielsweise muss die rendermethode des Renderplugins im gui plugin aufgerufen werden. Das Renedrplugin ist noch nicht im code integriert, würde aber genauso laufen.

Ich denke mit diesen Erläuterungen ist die Sache "much clearer".

Gruß Sebastian