Libreria di classi - Come comunicare tra oggetti che non sono a conoscenza l'uno dell'altro?

Se stai facendo un'interfaccia per i dati GPS, invariabilmente avrà una dipendenza dai dati GPS di qualche tipo. Avere quell'accoppiamento non è male, anzi. Se il controllo dell'utente dipende da un'interfaccia esplicita, stai permettendo al compilatore di dirti quando è mancante e stai dicendo ai tuoi utenti che cosa deve funzionare.

Tuttavia, rendendola un'interfaccia, stai effettivamente disaccoppiando il tuo controllo dall'implementazione del fornitore di dati GPS che le consente di cambiare liberamente. Il modo in cui la dipendenza viene fornita dipende dall'utilizzatore, che potrebbe persino utilizzare la propria fonte di dati, se lo desidera. Non c'è bisogno di contenitori IoC maledetti se non sono garantiti.

Poiché il UserControl è già stato disaccoppiato da GpsSensorUtil dagli eventi, non c'è bisogno di un'integrazione delle dipendenze da parte delle interfacce, il che complicherebbe solo le cose senza alcun beneficio aggiuntivo. Tuttavia, se ci sono molti eventi che devono essere collegati in un modo specifico tra questi due componenti, è un buon approccio non lasciare che questo gestisca ogni utente della tua libreria da solo, ma fornisca una funzione nella tua lib che questo per lui. E poiché non vuoi permetterti di conoscere UserControl di GpsSensorUtil , o viceversa, l'unico posto significativo è una classe aggiuntiva.

Quindi nella tua lib, fornisci una classe come UserControlBuilder o UserControlFactory che prende un oggetto GpsSensorUtil , crea un oggetto UserControl e fa il cablaggio degli eventi. Gli utenti della tua lib possono quindi utilizzarlo, quindi non hanno bisogno di scrivere il codice di cablaggio da soli (ma saranno ancora in grado di utilizzare GpsSensorUtil e UserControl completamente indipendenti l'uno dall'altro).

Non c'è bisogno di rendere UserControlBuilder un singleton, solo il fatto che un utente della tua libreria di solito avrà solo bisogno di un solo oggetto di quella classe non significa che la tua lib deve far rispettare che non ci saranno più oggetti di quella classe.

Se si desidera separare la costruzione di UserControl dal cablaggio degli eventi, ad esempio, per rendere più semplice l'uso di UserControl nella finestra di progettazione grafica dell'interfaccia utente, è comunque necessaria una classe aggiuntiva per il codice di cablaggio. In questo caso, chiama semplicemente la classe UserControlInitializer o qualcosa di simile e passa il UserControl e GpsSensorUtil precedentemente costruiti nella funzione di cablaggio fornita di quella classe.

Mantengalo semplice. GpsSensorUtil dovrebbe avere una proprietà evento e ControlUtil dovrebbe avere un gestore eventi pubblico. Quindi, nel codice principale che crea i due, dovresti avere una riga come gpsSensorUtilInstance.GPSEvent += controlUtilInstance.OnGPSEvent; . Nessun framework, nessun contenitore, nessuna dipendenza diretta tra le due classi.

Il modo di comunicare tra classi che non hanno conoscenza reciproca è tramite il passaggio di messaggi. Di solito c'è un bus o qualche altra forma di meccanismo di routing master che ogni classe registra con. Da quel momento in poi, ogni classe invia messaggi al bus senza alcun riguardo se un'altra classe li sta leggendo.

Quindi qui, la tua lib sta sparando eventi e la tua interfaccia utente li sta leggendo. Non è necessario conoscere nient'altro che il tipo di messaggi di eventi che riceveranno. Non c'è bisogno di interfacce o di collegamenti espliciti tra di loro, devono solo sapere come leggere e scrivere messaggi sul bus.

Funziona bene anche per sistemi distribuiti, quindi la tua lib GPS potrebbe inviare dati a un terminale remoto, se il tuo bus gestiva la trasmissione dei messaggi attraverso una rete anziché localmente.