Modi per evitare di utilizzare gli switch per associare le stringhe alle classi

Question

Modi per evitare di utilizzare gli switch per associare le stringhe alle classi

#1 da (2 voti)

0

Ho una soluzione C # che legge i record da un db e li elabora in un altro db. I record da elaborare sono essenzialmente una stringa lunga che rappresenta i dati e quindi un altro "codice" di stringhe che determina come deve essere analizzata la stringa di big data. Ci sono dozzine e dozzine di diversi tipi di documenti; Li ho rappresentati come distinte classi concrete che ereditano tutte da una classe astratta.

Posso generare il codice per rendere le classi per i diversi record abbastanza facilmente. Tuttavia, c'è un modo migliore (cioè meno verboso, più dinamico) per mappare il "codice" alla classe che lo rappresenta? In questo momento sto usando solo un interruttore enorme, qualcosa del tipo:

BaseRecord record;
switch(code) {
    case "A":
        record = new A(stringData);
    case "B":
        record = new B(stringData);
    .
    .
    .
    case "Z":
        record = new Z(stringData);

dove A, B, ..., Z derivano tutti da BaseRecord.

Oltre alla riflessione, non riesco a pensare a un modo per mappare le rappresentazioni di stringa dei nomi di classe alle classi che rappresentano.

object-oriented-design

posta Joseph 04.07.2015 - 13:53

fonte

1 risposta

Leggi altre domande sui tag object-oriented-design

Che cosa dovrebbero rappresentare i file e la cartella (Core, Risorse, Comune, Modelli, Risorse, Viste) nel mio progetto? Spring consuma REST interno WS per MVC

score 2 · Accepted Answer

Bene, è possibile per evitare l'istruzione switch : puoi creare una classe factory astratta e avere alcune classi da ereditare (idealmente tramite un argomento template) per produrre oggetti del diversi tipi derivati. Quindi puoi inserire tutte le fabbriche concrete necessarie in una mappa e utilizzare le stringhe per indicizzarle in quella mappa per produrre una fabbrica per il tipo dinamico desiderato.

Tuttavia, mentre è possibile, non vale la pena farlo. Per quanto posso vedere, la tua dichiarazione switch è incredibilmente semplice (anche se lunga). La fabbrica astratta introdurrebbe molta complessità aggiuntiva, quindi il switch sembra essere più conforme al principio KISS.

In generale, non c'è niente di male in un'istruzione switch , nemmeno una con molti casi (purché i casi siano semplici e autonomi). Il problema con le istruzioni switch è solo quando spuntano ovunque, il che indica che si dovrebbe invece usare l'ereditarietà. Mi sembra giusto un singolo switch per eseguire la deserializzazione.