Molte classi diverse che richiedono funzionalità simili. Miglior approccio?

Question

Molte classi diverse che richiedono funzionalità simili. Miglior approccio?

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Ho molte (al momento circa 30) diverse classi di messaggi in un'applicazione che sto creando. Ognuno di questi messaggi deve essere serializzato e deserializzato. Tuttavia, il processo di serializzazione e deserializzazione è per lo più unico per ogni classe (il formato del messaggio serializzato è specificato in un documento e dice quali bit nel messaggio vanno dove), ma alcuni sono piuttosto semplici e usano lo stesso processo.

Ho pensato di far implementare ciascuna un'interfaccia, con i metodi Serialize() e Deserialize() . Tuttavia, sembra complicato implementare questo per ogni messaggio, specialmente quando molti dei messaggi usano di fatto lo stesso codice per fare questo serializzazione e deserializzazione.

Ho pensato di avere una classe che contiene Dictionary<T, Func<IMessage, byte[]> e una funzione per mappare una funzione per serializzare su un tipo specifico. Quindi utilizzare questo dizionario per ottenere il serializzatore appropriato.

Qualche idea? Come andresti su questo problema?

interfaces .net delegates

posta Walkingsteak 14.04.2015 - 15:09

fonte

3 risposte

Leggi altre domande sui tag interfaces .net delegates

Scelta di una licenza software che richiede un'autorizzazione scritta per l'uso commerciale Definire i criteri di accettazione per una storia utente

score 4 · Answer 1

Sembra che tu possa coprire tutto ciò usando l'ereditarietà diretta. Crea una classe base con un'implementazione comune e crea sottoclassi che sostituiscono quell'implementazione con il loro comportamento univoco.

Puoi leggere su MSDN qui .

EDIT: ho pensato di dover elaborare un esempio. Definisci una classe base che implementa il comportamento predefinito della tua (de) serializzazione.

abstract class Message {
   public virtual void Serialize() {
      // Default logic here
   }

   public virtual void Deserialize() {
      // Default logic here
   }
}

La tua classe derivata può quindi sovrascrivere questi metodi e, se necessario, specificare il proprio comportamento.

class SpecialMessage : Message {
   public override void Serialize() {
      // Specific logic here
   }

   public override void Deserialize() {
      // Specific logic here
   }
}

Qualsiasi classe che eredita dalla classe Message che non sovrascrive questi metodi, utilizzerà i metodi predefiniti definiti nella classe base.

score 1 · Answer 2

Risposta generica: la mia sensazione istintiva dice che se hai 30 cose diverse ma molto simili, dovresti andare su un metalevel, avere una classe per tutti e spingere la differenza fino ai dati. Anche se si finisce con un nano VM / nano interprete. Forse durante l'implementazione, scopri che ne hai solo due o tre, parametrizzabili da diversi tipi di dati.

score 0 · Answer 3

Suggerirei di inserire il codice di serializzazione e deserializzazione in classi separate piuttosto che nelle classi del modello di dati come se stessero pensando.

Sto risolvendo un problema simile ora e ho tre gruppi distinti di classi. Il primo è il modello per i messaggi che contengono i vari campi del messaggio. Non c'è alcuna logica o validazione in essi, sono veramente DTO . Tutti i messaggi ereditano da un'interfaccia per i marker .

Il prossimo gruppo di classi è la classe di serializzazione e deserializzazione. Ho due interfacce: una per la serializzazione e l'altra per la deserializzazione. Ognuno di loro ha un metodo che accetta un messaggio e restituisce un tempo generico (per la serializzazione) e un metodo che restituisce un messaggio e accetta un tipo generico. Implemento questa interfaccia in serializzatori e deserializzatori per XML Strings (il generico è di tipo String), binario (il generico è di tipo byte []) e Proprietà (il generico è di tipo Proprietà).

Il gruppo finale di classi sono i miei validatori. Questi sono più di un raggruppamento logico che garantisce che i messaggi siano conformi alle specifiche. Restituiscono Elenco dei problemi di convalida, restituendo una Lista vuota se la convalida ha esito positivo.

Il vantaggio di questo approccio è che disaccoppia completamente i dati dei messaggi dalle regole dei messaggi dai processi di trasformazione e rende banale la creazione di nuovi set di regole o di formati di serializzazione / deserializzazione.