Interfaccia (contratto), Generics (universalità) e metodi di estensione (facilità d'uso). È un design giusto?

Question

Interfaccia (contratto), Generics (universalità) e metodi di estensione (facilità d'uso). È un design giusto?

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

0

Sto provando a progettare un semplice framework di conversione basato su questi requisiti:

Tutti gli sviluppatori devono seguire un insieme predefinito di regole da convertire dall'entità di origine all'entità di destinazione
Alcune norme generali dovrebbero poter essere applicate in un luogo centrale, senza interferenze con il codice degli sviluppatori
Sia la creazione di convertitori che l'uso di classi di convertitori dovrebbero essere semplici

Per risolvere questi problemi nel linguaggio C #, mi è venuto in mente un pensiero. Lo sto scrivendo qui, sebbene non si compili affatto. Ma supponiamo che C # compili questo codice:

Creerò un'interfaccia generica chiamata IConverter

public interface IConverter<TSource, TTarget>
    where TSource : class, new()
    where TTarget : class, new()
{
    TTarget Convert(TSource source);

    List<TTarget> Convert(List<TSource> sourceItems);
}

Gli sviluppatori implementerebbero questa interfaccia per creare convertitori. Ad esempio:

public class PhoneToCommunicationChannelConverter : IConverter<Phone, CommunicationChannle>
{
    public CommunicationChannel Convert(Phone phone)
    {
        // conversion logic
    }

    public List<CommunicationChannel> Convert(List<Phone> phones)
    {
        // conversion logic
    }
}

E per semplificare l'utilizzo di questa classe di conversione, immagina di aggiungere static e this parole chiave ai metodi per trasformarli in Metodi di estensione e utilizzarli in questo modo:

List<Phone> phones = GetPhones();
List<CommunicationChannel> channels = phones.Convert();

Tuttavia, questo non viene nemmeno compilato. Con questi requisiti, posso pensare ad altri progetti, ma a loro manca un aspetto. O l'implementazione diventerebbe più difficile o caotica e fuori controllo, o l'utilizzo diventerebbe veramente difficile. Il design è giusto? Quali alternative potrei avere per raggiungere tali requisiti?

design c# type-conversion

posta Saeed Neamati 21.08.2014 - 12:26

fonte

2 risposte

Leggi altre domande sui tag design c# type-conversion

funzioni di ordine superiore costrutto equivalente in TIOBE top 10 lingue [chiuso] Dovrei preoccuparmi delle prestazioni, anche se non ci sono perdite di convenienza? [duplicare]

score 4 · Answer 1

Potresti semplicemente definire un operatore esplicito per eseguire la conversione direttamente nella classe Phone in questo modo:

public class Phone 
{
     // your Phone props here

     public static explicit operator CommunicationChannel(Phone phone)
     {
          return new CommunicationChannel { PropQ = phone.PropZ };
     }
}

Per utilizzare l'operatore, basta effettuare Phone come CommunicationChannel:

List<Phone> phones = GetPhones();
List<CommunicationChannel> channels = phones.Select(phone => (CommunicationChannel)phone).ToList();

score 1 · Answer 2

Ho dovuto specificare molte conversioni di tipo personalizzato nel mio progetto e ho avuto molto successo usando solo un pezzo di codice dal progetto EmitMapper

Emitmapper: StaticConvertersManager.cs

Puoi semplicemente creare classi con funzioni statiche che hanno un parametro con un tipo e restituiscono un altro tipo e puoi registrarle con questo gestore

Mi ha salvato un sacco di tempo