Plugin

Si certo perchè il discorso non è ancora finito... chiaramente.

Si supponga di dover creare un applicazione che carica autonomanente i propri plugin, si supponga inoltre che questi risiedono esclusivamente in un unico folder noto all'applicativo (dicitura presente nelle configuarazioni)

Si supponga inolte che il plugin abbia (debba avere) fondamentalmente due possibili metodi:

1. GetName
2. Show

il primo restituisce il nome del plug, mentre il secondo consente l'attivazione. E' possibile che serva molto altro rispetto quanto detto, ma queste sono sicuramente le fondamentali.

E' quindi il caso di creare un Interfaccia in modo che tutti i plugin debbano per forza avere questi metodi.

Chiaramente il plugin stesso avrà molte funzionalità in più, ma saranno esclusivamente del plugin, e quindi finalizzate alla funzionalità del plugin stesso.

Ci sarà quindi un tipo base di plugin a cui tutti i nuovi plugin dovranno fare riferimento, e che non da meno
esporrà forzatamente l'interfaccia GetName e Show.

Non da meno c'e' da considerare il fatto che non si stia facendo il caricamento di un solo elemento, ma di una vera
e propria collezione, ossia un insieme di elementi fisici e logici Tipizzati come plugin.

In questo modo sarà possibile in ogni momento accedere a questa lista ed eventualmente effettuare ogni possibile
valutazione (vedi abilitazioni per utente).

Il loader, ossia chi si occupa di individuare i plugin e caricarli.

Il manager chi si occupa di trasformare i nostri plugin.



Alla fine dovreste ottenere qualcosa non troppo distante da questo.

Si tratta di un esempio,che serve esclusivamente a capire che una struttura come questa non è semplice da implementare a posteriori.

Perchè evidentemente gli impatti possono essere troppi e troppo costosi da gestire.

E' quindi fondamentale effettuare parecchio studio prima di creare un approccio approssimativo. E' fondamentale comprendere se questo tipo di implementazione è davvero necessario.

Va de se che un applicazione piccola, single user, e strutturata su misura per un utente, potrebbe non richiedere questa strutturazione.

Ma tutto questo non è del tutto sufficiente.

Consideriamo che i plugin sono semplicemente elementi che vengono individuati tramite una lettura di una directory, e se rispecchiano le regole (come ad esempio un prefisso plg_ ) vengono associati a delle voci di menù.

E' corretto pensare che fino a questo punto nessuna delle classi che ho elencato si occupa di gestire l'effettiva gestione
della voce di menu e quindi di caricare effettivamente i plugin.

Quindi facendo un analisi più approfondita si otterrebbe qualcosa di simile a questo schema:

Dove IPlugin rimane comunque l'interfaccia, a tutti i plugin che implementerò ( vedi customPlugin)
Dove il plugin Manager si occuparà interamente delle gestione degli elementi
Dove il plugin Factory si occuperà di leggere l'elenco di plugin.

*
Sarà inoltre compito del plugin manager caricare ed eseguire il metodo show del plugin.
si noti il metodo DoPluginAction a tutti gli effetti è delegato all'azione del menù
newmenuItem.Click += new EventHandler(DoPluginAction);

Certo il concetto non è semplice. Si tratta come scopo ultimo di creae un applicazione che sia capace di individuare in autonomia tutto ciò che gli vine aggiunto a run time.

Ad ogni restart nell'applicazione verranno individuati i nuovi plugin e caricati nell'apposito menù.

Ci sono parecchi vantaggi nello scrivere un applicazione a plugin, come mi pare di aver già accennato il primo fra tutti e che una volta scritti codice e regole per il caricamento, con questo metodo ci basta solo implementare l'interfaccia iPlugin nella nostra nuova funzionalità-

Fra gli svantaggi posso sicuramente annoverare la scarsa possibilità di creare nidificazione fra funzionalità.
Gli utenti per esempio saranno finalizzati a loro stessi ... questo potrebbe essere un problema ma il tutto dipende
da come analizzare e implementare le varie funzionlità.