Come posso evitare entrambi gli oggetti A e B utilizzando la classe C (o è inevitabile)?

Naviga le tue risposte
4

Ho la seguente configurazione:

  • Un oggetto A in esecuzione come servizio separato con un proprio indirizzo (implementato tramite pacchetto Pyro in Python).
  • Un oggetto B in esecuzione come servizio separato con il proprio indirizzo.
  • Oggetto C utilizzato come veicolo per il trasporto di dati tra A e C.

Caso di utilizzo:

  • A crea C e lo invia a B per l'elaborazione.

Ciò che mi infastidisce:

  • Ho bisogno di importare la definizione della classe C sia in A che in B.

Domanda principale:

  • È normale? Ho davvero bisogno di avere C in una libreria comune? Non sarebbe un problema se A è seduto su un server, B su un altro e la libreria comune (con C) cambia?

Domanda laterale:

  • Vado per un ibrido di sistemi orientati agli oggetti e agli eventi. Questo setup sembra proprio? Non ho molta familiarità con la terminologia per i paradigmi. È questa architettura basata sul servizio?
posta A.L. Verminburger 24.11.2016 - 15:52
fonte

2 risposte

5

Quando parlo con te devo importare un concetto chiamato inglese. Mi dà fastidio che tu debba importare anche l'inglese perché ci sono tutte queste donne francesi interessanti che rifiutano di importare l'inglese. Mi piacerebbe poter parlare con loro ma mi rifiuto anche di importare il francese.

Hai bisogno di un modo comune per comunicare. È possibile inviare una stringa, ma anche quella richiede un modo comune per comunicare. Stai solo usando il fatto che entrambi hanno già importato una stringa. Ovviamente dovresti ancora decidere quale sarà la stringa (json, xml, ini, ...) e come è strutturata (schema), quindi in realtà sei proprio indietro dove hai iniziato.

Un altro design sarebbe quello di creare un'interfaccia C che definisca solo ciò che deve essere comune. In questo modo B non si cura di C altro poi di come parlarne lasciando A libero di creare tanti diversi tipi di implementazioni C a suo piacimento.

In alternativa puoi usare il modello UN e creare la classe D il cui compito è tradurre AC in BC e viceversa. Questo è un sacco di lavoro extra quindi capisci che questo è un lavoro che ha senso solo perché nessuna delle due parti ha vinto le guerre anglo-francesi.

    
risposta data 24.11.2016 - 16:21
fonte
1

Non è raro ma non è il solo, o necessariamente il migliore, modo.

Due alternative comuni che ti vengono in mente:

  1. Stub client
  2. Message Broker

Stub client

In questo modello, un oggetto, ad esempio A, comunica con un livello molto sottile il cui unico compito è quello di inoltrare i dati all'altro oggetto. Dovrebbe avere solo il data marshalling e il codice di rete e basta.

Qualsiasi logica nel trasporto dovrebbe essere raggruppata nell'altra estremità, il lato server . Il vantaggio è che hai sempre solo bisogno di cambiare lo stub se la struttura dei dati cambia. Se fai attenzione, puoi scrivere in modo che raramente, se non mai, devi modificare questo codice.

Message Broker

Questo estende l'idea del client stub e ha stub alle due estremità. È quindi necessario un terzo processo per gestire l'interazione. È più complesso e presenta più modalità di errore, ma presenta il vantaggio del disaccoppiamento quasi completo delle funzionalità dal trasporto dei messaggi.

È utile se la logica di trasporto è complessa e / o è necessario inviare i dati a più di un oggetto destinatario.

    
risposta data 24.11.2016 - 16:28
fonte

Leggi altre domande sui tag

C'è qualche buona ragione per cui i classvari Python e l'ereditarietà del prototipo di JavaScript non mutano il genitore al momento dell'assegnazione? Come testare rami logici condizionali nidificati locali e variabili che non possono essere facilmente manipolati?