Descrizione del progetto:
Ho un progetto nodejs dove cerco di costruire una mesh bluetooth come la rete, ogni nodo è composto da circa 4 parti della parte frontale, il broker dei messaggi, un client bluetooth e un server bluetooth.
Il broker dei messaggi crea il server bluetooth, il client e tutte le dipendenze ed esegue il proprio processo del nodo, anche il server e il client bluetooth eseguono il proprio processo nodejs (Il server e il client scrivono payload di grandi dimensioni direttamente sul disco e fanno un po 'di conversione e compressione / decompressione in questi thread).
Questo broker di messaggi deve gestire i messaggi dal processo di frontend (richieste di fare qualcosa da parte dell'utente) e il client bluetooth (centrale) o il server bluetooth (periferica) (richieste da un altro nodo). I messaggi dal server e dal client saranno delegati a gestori di messaggi specifici. I messaggi di frontend sono gestiti dallo stesso broker.
Queste sono le mie classi relative al broker dei messaggi:
Dov'è il problema:
MessageBroker crea:
BluetoothClient ,
BluetoothServer ,
MetaDataManager (solo un oggetto per condividere i dati necessari tra broker, client e server, ma ora è diventato molto brutto ci sono più array per tenere traccia delle azioni in sospeso e delle richieste precedenti),
BluetoothStateController (tiene traccia dello stato dell'adattatore blutooth in modo che il broker, il client o il server possano verificare se il bluetooth è attivo e in tal caso se la sua scansione / pubblicità / connesso)
BluetoothClientMessageHandler (il messaggio boker passa tutti i messaggi dal client bluetooth a questa classe, a seconda dello stato, dei metadati e del messaggio ricevuto viene eseguita un'azione ad esempio connect - > leggi dati - > scrivi dati. di questo è asincrono quindi la risposta per l'azione connect, read e wirte arriva tutto nel metodo entry del gestore da cui è delegato ad un altro metodo)
BluetoothServerMessageHandler (Simile al client)
Qual è il problema: I gestori sono ciascuno circa 300 righe di codice con un sacco di condizionali (se altro e switch case) (i messaggi sono oggetti JSON dagli altri processi del nodo) e finora non sono riuscito a dividerli in classi più piccole perché i metodi sono troppo rigidi accoppiati, i gestori di messaggi gestiscono comunque una vasta gamma di messaggi (tipi diversi) quindi la prima cosa che ho pensato è stata dividerli in classi di gestori di messaggi (messaggi di errore, messaggi onDiscover, messaggi onConnect, messaggi readCompleted .... ).
So anche che la parola "gestore" significa che queste classi probabilmente sono ampie e non conformi al principio di responsabilità singola. Il principio di chiusura aperta è probabilmente anche violato a causa delle istruzioni caso switch all'interno dei gestori di messaggi.
Tentativo di soluzione:
Quando li ho divisi, al contrario di quello che mi sarei aspettato, ognuno di essi ha bisogno dello stesso numero di dipendenze (ad esempio il MetaDataManager), che non mi sembra una buona soluzione. Il broker dovrebbe creare ancora più gestori di messaggi (quindi sì, i gestori dei messaggi diventano più piccoli ma il broker dei messaggi diventa affollato ora) e il MetaDataManager potrebbe dover tenere traccia di altri dati condivisi.
UPDATE: Ho ripensato al mio tentativo di soluzione e ho pensato che potrebbe non essere così male se uso qualcosa come a Servizio di facciata come menzionato in this domanda per includere le dipendenze, ad es. Vorrei dividere i gestori di messaggi in gestori di messaggi specifici, creare dipendenze condivise in un'altra classe per contenere le dipendenze e un'altra per creare tutti i gestori di messaggi, il broker di messaggi quindi crea solo un'istanza della classe che crea tutte le dipendenze condivise e passa questo oggetto all'oggetto che avvolge tutti i gestori di messaggi.
Qualcuno vede un modo migliore per disaccoppiare queste classi?