Alternative all'utilizzo del dizionario nei parametri in C #?

1

Ho un metodo che accetta un dizionario e valore enum e produce un output di stringa. Il valore Enum definisce quale stringa modello inserire le coppie di valori chiave del dizionario in.

public string InsertVariables(MessageType type, Dictionary<string, string> variables) { }

Funziona bene, ma ogni volta che lo uso, trovo difficile sapere cosa aggiungere alle variabili per assicurarmi che tutti i token nel modello vengano sostituiti e devo sempre dare un'occhiata ai template.

Quello che pensavo avrebbe funzionato come soluzione in questo caso è applicare i valori corretti aggiunti alle variabili durante il tempo di compilazione in questo modo:

public abstract class MessageVariables { }

public class NewUserMessageVariables : MessageVariables {
    // different values go here parameters go here instantiated in the constructor
}

public string InsertVariables(MessageType type, MessageVariables variables) { 
    // converts variables object into dictionary for future insertion into the template.
}

Questo sembra far rispettare tutti i parametri richiesti nei messaggi.

Ho circa 16 messaggi con possibilità di averne altri in seguito.

DOMANDA: È eccessivo e dovrei limitarmi a usare il dizionario?

    
posta Alexus 26.06.2015 - 02:02
fonte

2 risposte

1

I tuoi dubbi sono validi. Stai usando un linguaggio strongmente tipizzato, ma avventurati in un'area debolmente tipizzata o non tipizzata. Succede, ma questo tipo di controllo degli errori / vincoli che stai chiedendo (se ben indirizzato) aumenterà la manutenibilità restituendoti i vantaggi di essere più strongmente digitato.

Quello che probabilmente farei è analizzare il modello per vedere quali variabili menziona. Quindi puoi avere una nozione di un modello normale, e anche, una nozione di controparte di un modello analizzato che ha anche un elenco di variabili richieste che devono essere legate per creare un'istanza. Tale analisi potrebbe essere automatizzata, o eseguita manualmente con gli ornamenti, ad esempio se si aggiungono informazioni sul tipo non presenti nel modello.

D'altra parte, annotare il modello (testo) stesso con le informazioni sul tipo potrebbe essere un buon approccio, in quanto consentirebbe all'automazione nello sviluppo della controparte modello analizzata che ha le variabili elencate.

Quindi puoi avere una nozione di istanziazione del modello analizzato, che può richiedere (o fallire in mancanza di) le variabili giuste. (Puoi anche controllare, se lo desideri, se alcune variabili fornite non sono nemmeno usate.)

Non sono sicuro che tu ti chieda se la tua preoccupazione vada più al tipo delle varie variabili piuttosto che assicurarti che siano tutte fornite (diciamo, più o meno non tipizzate).

In sostanza, mi piacerebbe cambiare l'enum in una classe (magari una classe base e un insieme di classi, anche una per ogni modello) che è / sono più descrittive di ciò che è richiesto riguardo alle variabili.

Se si va abbastanza lontano con la modifica dell'enumerazione in classi, si potrebbero trovare parametri di classe (modello) specifici (costruttore) che passano invece di un dizionario per poter funzionare.

Dato che sei in C # (e presumibilmente in Visual Studio), potresti utilizzare un modello T4 per generare le classi di interesse da alcuni file .tt prototipo, a seconda di come ti piacerebbe creare i tuoi modelli. Questo può funzionare molto bene per fornire classi OOP e tipi appropriati che desideri da definizioni dei dati modificate relativamente facilmente.

    
risposta data 26.06.2015 - 03:51
fonte
1

Dipende.

Se sopra c'è un codice che rafforza efficacemente l'invio delle variabili giuste (alcune forme per esempio), quindi è improbabile che si rompa frequentemente, quindi rendere ogni messaggio un suo tipo sembra eccessivo.

Se non c'è un codice sopra questo e ti affidi alla buona volontà del tuo programmatore per assicurarti che le cose siano ben formate ... Probabilmente è una scommessa sbagliata, e rendere l'interfaccia più solida ti servirà bene.

Non avrei alcun tipo di base MessageVariables a meno che non fornisca qualche vantaggio. E io personalmente commetterei un grosso errore verso classi / funzioni reali per ogni messaggio. Rende le cose più rilevabili e, a soli 16 messaggi, non è proibitivamente gestibile.

    
risposta data 26.06.2015 - 02:10
fonte

Leggi altre domande sui tag