Determinare quali classi di decoratori sono disponibili tramite riflessione

In generale non è un approccio negativo: se c'è un'interfaccia comune come "IPizzaTopping" e i tuoi nuovi assembly contengono elementi di quell'interfaccia, puoi estrarre tutte le cose in un assembly con quel tipo.

Detto questo, si tratta di overkill completo per qualcosa come le guarnizioni per la pizza (dove una configurazione xml potrebbe probabilmente bastare), ma ho visto che ha funzionato molto bene con le architetture dei tipi di plugin.

La domanda non è tanto se si debba o meno usare il reflection per costruire l'elenco di checkbox dal set di sottoclassi che hai definito. Una volta che hai fatto questa scelta, e vuoi mantenere la GUI aggiornata senza ricompilare o mantenere le possibili guarnizioni in due posti diversi (sempre un brutto segno), c'è poco altro che puoi fare per enumerare le classi (sarebbe diverso se si enumera istanze di classi fratelli, ma suppongo che non ci sia in realtà un repository persistente di oggetti Cheese, Tomato o Onion su cui è possibile eseguire l'iterazione.

La domanda dovrebbe piuttosto essere: è la rappresentazione di condimenti come classi l'idea giusta, o è eccessivo? Finché l'unica cosa caratteristica di un topping è ciò che rende la pizza decorata, potrebbero benissimo essere istanze parametrizzate della stessa classe . Avere più sottoclassi di solito è una buona idea quando uno o più comportamenti differiscono sistematicamente tra loro. Ad esempio, i framework su cui sono costruiti ambienti come Eclipse o NetBeans consentono ai contributori di scrivere plug-in estremamente potenti che tuttavia si integrano in un'installazione esistente, il che implica l'implementazione di dozzine di comportamenti diversi. Non sorprendentemente, le strutture stesse sono strongmente dipendenti dalla riflessione per ottenere la straordinaria flessibilità che offrono. Ma il tuo problema, penso, non è tanto un caso di riflessione eccessiva quanto un caso di ereditarietà eccessiva.