public interface IMyInputProviderPlugin
{
IMyOutput Provide(IMyInput data);
}
Questa è un'interfaccia che devo fornire in modo che possa caricare dinamicamente le DLL e non averle legate alla mia implementazione.
Tuttavia, leggendo questo, sembra che questo sia un anti-pattern?
Sono confuso, come si fa a farlo se non in questo modo?
Ogni schema tenta di risolvere una o più sfide nella progettazione del software e presenta una serie di svantaggi. Avrai bisogno di studiare i modelli che puoi utilizzare nella tua situazione e determinare ciò che più si adatta alle tue esigenze.
Il link che hai condiviso nella tua domanda è di Mark Seeman il cui libro di cui fa riferimento nell'articolo è incentrato principalmente su Iniezione di dipendenza (DI). DI impone molti principi di progettazione e ha molti vantaggi, e quindi ci sono molti contenitori DI sviluppati in varie lingue che possono essere utilizzati per DI. Il contenitore DI consente di applicare DI in modo più semplice e un tipico contenitore DI eseguirà la gestione del ciclo di vita dei vari tipi, inclusa la creazione di istanze. Se si sono utilizzati contenitori DI, è probabile che non sia necessario utilizzare il modello di provider.
Tuttavia, nella mia esperienza personale, ci sono situazioni in cui uno non usa un contenitore DI e il codice ha bisogno di localizzare un servizio e usarlo (molto simile a quello che si prevede di fare). Questo modello è chiamato modello di localizzazione del servizio , e il modello di provider può essere considerato una specializzazione di questo design pattern. Pertanto, vedrai che ci sono sviluppatori che non saranno d'accordo con Mark Seeman. (FYI, leggere i commenti, se possibile, di entrambi gli articoli per i disaccordi).
Alla fine, dipende da te determinare cosa soddisfa le tue esigenze al meglio. Ho usato un'iniezione di dipendenza e qualcosa di simile al modello di provider, ed entrambi soddisfano determinati bisogni e in alcuni casi uno è preferibile rispetto all'altro. Ad esempio, se dovessi fornire la possibilità della mia applicazione in esecuzione di essere in grado di caricare un altro modulo fornito esternamente e di gestirne il ciclo di vita senza chiudere l'applicazione principale, sono piuttosto propenso ad andare con il modello del provider e in genere finirà scrivere codice personalizzato per esercitare il controllo completo sulle interfacce.
IMO, dovresti valutare i pro e i contro di ogni approccio (magari anche il prototipo se necessario) e andare con quello che è più probabile che funzioni con te invece di scavare troppo nella questione se si tratti di un "modello" o "anti-pattern".
Leggi altre domande sui tag design-patterns