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

[jabjoint]

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...

Ho capito...bhé è un peccato sia lento...in effetti...

[jabjoint]

Mi sa che il problema è proprio qui.


Non si capisce se stai parlando di database, di SQL, di ADO.NET, di LINQ 2 SQL, ma a prescindere da tutto questo, ciò che dici è sempre possibile comunque, a prescindere da tutto il "castello di sabbia" che stai faticosamente costruendo e che continua a non avere un senso apparente.

Dovrò quindi preparare un enciclopedia la prossima volta per fare una domanda?

Ma...non so che vi è preso tanta arroganza!

[optime]

ci riprovo, che te vai a sape' che ottengo risposta

@jabjoint, quindi hai solo una classe Articoli?

[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.

[U235]

Visto alcuni post, spero che questa discussione si possa "terminare" senza i soliti attacchi reciproci, a prescindere da chi abbia ragione o torto. Non credo che ci sia bisogno di rispondere a tutti i costi se qualcuno ci sembra che ci manchi di rispetto, basta lasciare cadere alcune affermazioni.
Poi ovviamente ognuno è libero di fare come crede.

[alka]

In genere queste cose sono tese a rendere riutilizzabile il codice [...]

Conosco bene le tecnologie e le librerie, quindi siamo perfettamente d'accordo sul teorico.

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.

No, non è una questione di "moderazione" ossia quantitativo, quanto di "contesto utile": se parliamo ad esempio di Reflection, il punto non è limitarne l'uso per mantenere una moderazione, ma usarlo solo nel contesto in cui tale API risulta utile ed efficace proprio per lo scopo a cui sono rivolte. Se non serve, la Reflection non si usa neanche "un pochino".

Ad ogni modo, la mia contestazione continua a riferirsi a cose non tecniche ma di comportamento e di uso corretto del forum.

Non credo che ci sia bisogno di rispondere a tutti i costi se qualcuno ci sembra che ci manchi di rispetto, basta lasciare cadere alcune affermazioni.

Da moderatore di quest'area del forum, se viene utilizzata in modo improprio o non c'è il rispetto del luogo e delle finalità di questo spazio, non "lascio cadere" nulla ma anzi intervengo e segnalo il problema indicandone la soluzione.

Se poi non viene rispettata, si segnala la questione all'admin e si prendono provvedimenti.

Non lo dico a te, ma mi riferisco alla persona a cui più volte sono state rivolte richieste di chiarezza e che ha aperto a oggi diverse discussioni sullo stesso problema, senza chiarire a dovere di cosa si tratta, senza rispondere alle domande che vengono poste dagli utenti per capire e ignorando completamente tutte le indicazioni che vengono date.

Non siamo in un luogo anarchico: i comportamenti scorretti non vengono tollerati.

[alka]

Dovrò quindi preparare un enciclopedia la prossima volta per fare una domanda?

Non facciamo i furbi portando le questioni all'estremo.

Ti è stato fatto presente che

1) poni i quesiti in modo incomprensibile nella forma,
2) mancano i dettagli per definire la problematica nello specifico,
3) non rispondi alle domande poste dagli utenti per chiarire (vedi post di optime qui),
4) lasci le discussioni in sospeso senza una soluzione finale quando sostieni di avere risolto (tipo questa),
5) abbandoni le discussioni completamente lasciando questioni in pending, a prescindere da soluzione trovata o meno (vedi questa).

Ognuna di queste cose "non s'ha da fare".

Ma...non so che vi è preso tanta arroganza!

Vedi i punti sopra, già tollerati fin troppo, e vedrai da chi arriva l'arroganza.
Se c'è qualcosa di non chiaro, sono disponibile a spiegarlo.

Se vengono reiterati, segnalo la questione all'admin.

Chiudo qui la questione perché ho perso già troppo tempo in richiami e polemiche inutili.

[U235]

. (rispetto la chiusura)

[alka]

. (rispetto la chiusura)

Ho chiuso la questione specifica sulle problematiche sollevate, nel senso che ho chiarito in via definitiva quali sono, ma non ho chiuso la discussione in sé, nel caso si volesse proseguire con la trattazione del problema, magari rispettando appunto le osservazioni fatte.

[U235]

Mi sembra comunque che quello che dovevo dire a jabjoint sia in stallo senza ulteriori post da parte sua.
Per il resto sarebbe stata una risposta pressoché inutile.
Spero di aver risposto alla tua domanda e mi sembra che in linea di massima non ci sia necessità di discutere ulteriormente, visto che mi sembra che siamo in accordo, se non per qualche sfumatura poco importante. A meno che non abbia tu piacere di continuare a discutere.
Anche per quello ho cancellato il post, le ritenevo sfumature poco utili per giustificare una controbattuta.