Progettazione software OO per interfacciamento hardware

Hai menzionato le porte COM, quindi parlerò specificamente di quel caso.

• Designing and structuring classes around hardware interfaces to maximize encapsulation.

Ci sono due modi per utilizzare le porte COM, Comando / Risposta e Streaming. La modalità di progettazione dell'interfaccia dipenderà dal modo in cui si prevede di utilizzare la porta. A volte leggerete e scrivete sul dispositivo o aprirete un flusso costante di dati da un dispositivo a un altro?

Per Comando / Risposta creerei un'interfaccia asincrona come questa.

public interface IDevice : IDisposable
{
    // Sends command without listening for a response
    Task Send(Command command);

    // Sends Command and waits for response
    Task<Response> Send(Command command);

    // Sends Command and listens for Response. Cancellable
    Task<Response> Send(Command command, CancellationToken token);
}

Per lo streaming di dati, solitamente utilizzo la classe Stream con un StreamWriter personalizzato o StreamReader .

In entrambi i casi, vuoi essere sicuro di avere interfaces o abstract su cui contare, perché ti consigliamo di prendere in giro l'hardware per testare altre parti del tuo codice.

• How to handle initialization and releasing/destroying of the hardware and their wrapping/related class.

Hai fondamentalmente due opzioni per l'inizializzazione qui. Puoi aprire lo stream nel costruttore o fornire un metodo Open() . O funzionerà e entrambi hanno i loro pro e contro. Aprire la connessione nel Ctor significa che potresti ottenere delle eccezioni dal Ctor e ad alcune persone questo non piace. D'altra parte, avere un metodo che deve essere chiamato prima di usare una classe è un tipo di accoppiamento temporale a cui molte persone non tengono conto. È facile dimenticare di chiamare il metodo per mettere effettivamente la classe in uno stato utilizzabile. Quindi, scegli quello che si adatta meglio alla sensibilità della tua squadra.

Per la de struttura, ti consigliamo di implementare l'interfaccia IDisposable in modo da poter chiudere e rilasciare la porta in modo controllato e affidabile.

using( var device = new Device("COM5")
{
    // do stuff with port
} 

Quando esci dal blocco using , viene chiamato il metodo Dispose() che hai implementato, rilasciando la porta.

• How to store hardware state (for example storing the state in the hardware wrapper-class, a context vs. always querying the hardware, when a state is requested).

Di solito non immagazzino molto stato. Normalmente stiamo interrogando l'hardware per qualunque sia lo stato corrente e per il rifiuto.

• How to make this fit in with OO best practices, in particular dependency inversion.

Tratta l'hardware come se trattassi un database. Codice per interfacce anziché implementazioni. Abbiamo creato un interface che rappresenta il nostro hardware e un'implementazione di tale interfaccia, quindi qualsiasi codice client si basa sulla nostra interfaccia IDevice . Il costruttore ti inietta l'implementazione come faresti con qualsiasi altra classe.

public class Foo
{
      private readonly IDevice _device;

      public Foo(IDevice device)
      {
           _device = device;
      }

      //...
}

In realtà, in genere iniettare una fabbrica anziché un esempio in cui ho a che fare con IDisposable per semplificare i test.

Potrebbero esserci delle dipendenze sul tuo hardware specifico. Per esempio. nel nostro caso, inviamo un comando all'avvio affinché l'hardware esegua alcuni passaggi di inizializzazione / calibrazione. Il nostro hardware non accetta i nuovi comandi prima che abbia finito di inviare la sua risposta al comando precedente (sebbene l'azione avviata dal comando possa durare "per sempre" - ma il acknowledge deve essere ricevuto prima del comando successivo). Preferisco i comandi Start e Stop nell'interfaccia (quindi funziona anche con l'iniezione delle dipendenze).

Per comunicare via porta seriale, abbiamo estratto un'interfaccia semplice ISerialPort e aggiunto un SerialPortWrapper che contiene un'istanza .Net SerialPort e espone l'interfaccia (che ci consente di scrivere alcuni manichini che potrebbero inviare un errore hardware specifico risposte per i test).

Anche un'applicazione multi-thread deve assicurarsi che i comandi non vengano inviati contemporaneamente sulla porta. Facciamo attenzione che esista un solo wrapper per porta COM e un meccanismo di sincronizzazione appropriato in quell'istanza wrapper.

Gli errori inviati dall'hardware sono inclusi in ErrorEvent quando viene utilizzato un thread per il monitoraggio del dispositivo. Non puoi utilizzare Exception in quel contesto poiché ucciderebbe solo il thread di monitoraggio.

Lo stato del dispositivo viene interrogato meglio dal dispositivo, se riesce a farcela (ho riscontrato problemi con le query ad alta frequenza, potrebbero esserci problemi di interrupt nel dispositivo); in alternativa, una cache può decorare la classe di comunicazione e riemettere una query a seconda dell'ora in cui il valore è stato interrogato per ultimo.