[C#] Ottenere una Classe dal suo nome passato come parametro String?

[U235]

Nonostante la tua spiegazione, che almeno usa termini corretti, mi sfugge completamente l'utilità di una simile implementazione e non vedo che tipo di semplificazione potrebbe portare.


Già si parla di "ereditare", che in genere è un imbrigliamento, soprattutto applicati a classi che vengono tendenzialmente generate a partire dal DB (se si fa reverse engineering) e quindi facilmente sovrascritte, per fare una implementazione basata su Reflection che è estremamente lento. Boh...

In genere queste cose sono tese a rendere riutilizzabile il codice, oltre ad avere delle linee comuni tra il team e separare completamente gli strati dell'applicazione senza necessità di coordinarsi continuamente, a patto che si seguano le linee guida comuni a tutti.
Inoltre usare l'ereditarietà e la reflection è una cosa che in alcuni pezzi del sistema (ma per la reflection, si parla di pezzi limitati del sistema, non di basare tutto su quello che diventerebbe lento in alcuni casi) rende possibile cose che altrimenti sarebbero più complesse o addirittura impossibili. In genere è meglio usare le interfacce piuttosto che le classi, perché, e forse non serve che te lo dica io, quando parliamo di ereditarietà non parliamo solo di classi per recuperare la loro implementazione, ma anche di costituire un "contratto" dettato dal tipo di interfaccia, proprio per fare in modo di usare in maniera generica tipi diversi nello stesso modo.


Un esempio (molto limitativo) potrebbe essere il caso in cui hai un "grafico" che si occupa dello xaml, e potrebbe decidere di applicare un filtro arbitrario ad una lista (poniamo un listbox). Supponiamo che il programmatore mette a disposizione di tutti i viewmodel (tramite un viewmodel base comuni a tutti) un command che si occupa di filtrare la lista che verrà utilizzata dal grafico nel listbox, viene da se che se questa lista sarà trattata sempre con delle query linq, queste saranno sempre basate su where, ciò che cambia sono ad esempio i campi e i valori, quindi sarebbe comodo avere una struttura di tipo generico che esegue una query parametrizzata sui campi e valori passati come argomenti dallo xaml. In primo luogo per evitare di ripetere lo stesso command (e la parte sottostante ovviamente) per tutti i viewmodel che espongono una lista, poi la lista stessa, ed infine per non dover ricorrere al programmatore quando si vuole gestire vari parametri, soprattutto quando è l'utente finale a doverli scegliere magari mixandone diversi a sua scelta. Ma quest'ultimo passaggio è legato parzialmente, e andrebbe fatto un discorso a parte. In ogni caso se generi un viewmodel generico base che accetta un tipo T, dove T è derivato da una base con tutto il necessario per trattare le entità compatibili (liste; filtri; liste relazionate; proprietà comuni ecc.), al grafico serve sapere solo come trattarle per creare le sue "robe" grafiche (es: impaginazioni; filtri; visualizzazioni parziali) senza dover necessariamente coordinarsi continuamente con il programmatore. Inoltre al grafico potrebbe bastare anche usare il viewmodel generico (ad esempio con command aggiungi; rimuovi; salva ecc.) passando il tipo (derivato dalla tabella) per avere un viewmodel adattabile a determinati elementi, senza che nessuno gli abbia fatto un viewmodel apposito. Fermo restando che il programmatore che vuole ampliare detto "command" può sempre farlo recuperando parte di quello già scritto ( o comunque modificarlo del tutto) senza andare ad influire sul resto delle classi che fanno uso della semplice base.


Purtroppo, come spesso dici anche tu, per spiegare bene questo sarebbe necessario un piccolo corso, è difficile spiegarlo in un paio di post, a meno che non si voglia affrontare per bene il discorso correlato soprattutto da esempi. Sempre tenendo presente che dopo aver speso tempo per farlo, potrebbe non piacere soggettivamente o non essere utile se non si prevede una certa organizzazione del codice. Leggasi: si applica solo a grossi software con un vasto team intercambiabile, oppure se piace strutturare in maniera molto decisa il codice con delle linee guida molto definite.


Un ultima nota: se parliamo di software che hanno bisogno di ottimizzare in tutto per tutto la velocità, certamente conviene spendere molto più tempo per lo sviluppo per recuperare magari anche qualche millesimo di secondo. Ma bisogna considerare che una buona parte dei software non hanno bisogno di guadagnare velocità di esecuzione nell'ordine dei secondi. Ovviamente non intendo dire quando una cosa cambia di molto, ma in linea di massima, se si vogliono contenere costi e tempi a volte il guadagnare qualche centesimo o qualche secondo, non è poi così influente. Diciamo che se Microsoft ha introdotto nei suoi prodotti certe funzionalità, un motivo ci sarà pure, no?!? Basta usarle come e dove servono con la dovuta moderazione.