Come supporto le interfacce per dispositivi diversi nello stesso scenario di input?

0

Ho fatto questa domanda su SO, ma qualcuno ha sottolineato che sarei stato meglio qui. Probabilmente ha ragione. Quindi eccomi!

Quindi volevo solo un'opinione. Ho 2 modi diversi per affrontare il problema. Va bene, quindi ho un sistema che voglio progettare per il futuro. Ho alcuni tipi di oggetti che prendono come parametri un oggetto che implementa un'interfaccia che può contenere un altro oggetto Implementare un'altra interfaccia e così via.

In questo modo ho

A(InterfaceB B)->B(InterfaceC C)->C(InterfaceD D) ...

Finché non arrivo ad un punto in cui l'oggetto non ne contiene un altro. Ogni interfaccia implementa un'interfaccia comune. Quindi ho

Parent->InterfaceB   ---   Parent->InterfaceC   ---   Parent->InterfaceD

Ma InterfaceD non implementa necessariamente InterfaceB. Poiché un'interfaccia non ha una sola implementazione, ho più alberi possibili.

A(InterfaceB B)->B(InterfaceC C)->C(InterfaceD D)->...

e

A(InterfaceB B)->B(InterfaceC Y)->Y(InterfaceZ Z)->...

Quindi la mia domanda è questa: se voglio gestire gli alberi possibili, è meglio usare il reflection per generare gli alberi possibili all'avvio? O sarebbe meglio tenere gli alberi diversi in un file xml che analizzerei all'avvio? Devo tenere a mente che questi tipi di interfaccia e le loro implementazioni continueranno ad arrivare. Quindi ogni volta che aggiungo un nuovo tipo, deve essere gestito. So che entrambe le soluzioni funzioneranno. La mia domanda è più la seguente: quale sarebbe l'approccio migliore per orientare il sistema verso il futuro.

Per aggiungere un contesto alla situazione, ecco un esempio di caso

Tutte queste interfacce espongono un adattatore. Ogni adattatore potrebbe averne bisogno di un altro per svolgere il proprio compito. Ad esempio, ho un adattatore che analizza alcuni dati. Ma poi questi dati devono essere comunicati con un obiettivo remoto. Per fare ciò può usare ethernet, porta seriale, ecc ... Quindi potrei avere un parser generico che prende un comunicatore generico. Questa è una delle diverse possibilità.

Se hai bisogno di chiarimenti, non esitare!

    
posta Charles 21.09.2013 - 19:51
fonte

3 risposte

0

Ho riflettuto su questo, e credo che il tuo approccio con le interfacce sia contro-intuitivo. Se hai davvero bisogno di questo tipo di flessibilità, le interfacce sono l'opposto di quello che vuoi, perché le interfacce stabiliscono specificità, non generalità.

A meno che, naturalmente, non hai una singola interfaccia che assomigli a questa:

public interface ICommand
{
    void Execute(string command);
}

Che è in realtà ciò che ti suggerisco di fare. Puoi fare quella stringa tutto ciò che vuoi; nessuna necessità di ulteriori interfacce.

Se vuoi renderlo un po 'più sofisticato, puoi passare XML al tuo comando e deserializzare su un'istanza di un tipo. Puoi persino renderlo polimorfico aggiungendo un parametro che specifica il tipo a cui vuoi deserializzare.

Il mio punto è che provare a specificare l'interfaccia di comando usando le interfacce è de-generalizzare, che è l'opposto di quello che vuoi.

    
risposta data 24.09.2013 - 17:55
fonte
0

Penso che tu stia riflettendo su un argomento troppo in alto. Questo è un problema di elaborazione del segnale. Il percorso che seguirò è quello di avere un bus dei messaggi che i tuoi input (o chiamiamoli produttori) inviino messaggi e che i tuoi adattatori (o consumatori) ascoltino. I tuoi consumatori possono essere responsabili della trasformazione dei messaggi in modo che un altro consumatore possa comprenderli. Per renderlo altamente adattabile, i consumatori dovrebbero essere responsabili di una cosa e di una cosa sola. Quindi un consumatore sarebbe responsabile della trasformazione di un messaggio, un altro sarebbe responsabile di prendere un messaggio specifico e generare output.

Un ottimo libro da leggere per suggerimenti su come creare un sistema del genere sarebbe Enterprise Integration Patterns.

    
risposta data 24.09.2013 - 18:32
fonte
-3

Risponderò alla tua domanda con una domanda. Perché hai bisogno di gestire gli alberi in modo tale che tu debba sapere cosa contiene cosa?

Il punto delle interfacce è quello di creare un contratto astratto in cui l'utente non ha bisogno di sapere cosa fa l'oggetto e come lo fa. Tutto l'utente ha bisogno di sapere è l'interfaccia. Sapere cosa è contenuto in ciò che viola i confini dell'oggetto.

Il sistema dovrebbe essere in grado di srotolare se stesso alla fine senza che tu debba conoscere i dettagli specifici di cosa contiene cosa.

    
risposta data 22.09.2013 - 14:39
fonte

Leggi altre domande sui tag