È una cattiva pratica per un modulo contenere più informazioni del necessario?

Ottenere informazioni da una parte di un programma a un'altra è una battaglia costante e c'è quasi mai una soluzione perfetta.

Posso vedere quattro possibili soluzioni in una situazione come questa:

1. Basta andare avanti e includere le informazioni di cui C ha bisogno nella chiamata a B

2. A chiama C con tutte le informazioni e C chiama B con solo le informazioni di cui B ha bisogno

3. Inserisci tutte le informazioni in un oggetto neutro accessibile sia a B che a C e lascia che ognuna di esse ottenga ciò di cui ha bisogno

4. A chiama B con solo le informazioni di cui B ha bisogno, B restituisce pass / fail, A chiama C con informazioni C ha bisogno (introduce la dipendenza di A su C ma rimuove la dipendenza di B su C)

La "migliore" soluzione dipenderà dalle circostanze che effettivamente esistono in ogni situazione specifica.

Sono d'accordo con Larry OBrien che la soluzione migliore è probabilmente avere una chiamata B, quindi quando B torna, A chiama C.

Se davvero non puoi farlo, prenderei in considerazione il fatto che A passa un handle opaco a B, che poi passa a C. C può quindi passarlo a A per ottenere l'accesso alle informazioni di cui ha bisogno.

In un'implementazione tipica, A memorizza nella cache le informazioni e l'handle sarebbe in realtà qualcosa come un valore hash o un indice in una tabella. Supponendo che i dati non siano più necessari dopo essere passati a C, A scaricherà anche i dati dalla cache dopo averli passati a C in risposta all'accesso tramite l'handle.

Se B non può fare il suo lavoro (che include dire C pass / fail) allora A non gli sta dando tutte le informazioni di cui ha bisogno, vero?

Aggiungi le informazioni o rendi che non facciano più parte del lavoro di B.

module A giving more information to module B which it doesn't need to do it's job

Word "need" potrebbe confondere a meno che non si specifichi chiaramente needs . È vero che il modulo B non ha bisogno di queste informazioni per ottenere il risultato dell'elaborazione, ma è anche vero che senza queste informazioni, i suoi risultati sono inutili per il modulo C. In questo senso, le informazioni aggiuntive soddisfano un diverso tipo di necessità - un integrazione bisogno.

POSA 2 presenta un modello destinato a servire necessità simili - Token di completamento asincrono :

This design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services. (quoted from POSA 2 patterns abstracts page)

Il libro presenta un esempio di vita reale per aiutare a capire il modello: monitoraggio dello spazio pubblicitario FedEx

...An intriguing real-life example of the Asynchronous Completion Token pattern is implemented by the inventory tracking mechanism used by the US Federal Express postal services. A FedEx Airbill contains a section labeled: 'Your Internal Billing Reference Information (Optional: First 24 characters will appear on invoice).' The sender of a package uses this field as an ACT. This ACT is returned by FedEx (the service) to you (the initiator) with the invoice that notifies the sender that the transaction has completed. FedEx deliberately defines this field very loosely: it is a maximum of 24 characters, which are otherwise 'untyped.' Therefore, senders can use the field in a variety of ways. For example, a sender can populate this field with the index of a record for an internal database or with a name of a file containing a 'to-do list' to be performed after the acknowledgment of the FedEx package delivery has been received.

Vedi, sopra l'esempio è abbastanza vicino a ciò che descrivi. I ragazzi "nel mezzo della catena FedEx" possono dire che non hanno davvero bisogno di riferimenti di fatturazione, tutto quello che devono sapere è l'indirizzo di consegna. Ma il mittente può usarlo quando devono essere avvisati del completamento della transazione. È un'esigenza di tipo integrazione .

Per completezza di nota, c'è un approccio che evita la necessità di passare le informazioni di "identificazione" al modulo B. Il modulo B potrebbe restituire i suoi risultati al modulo A dalla chiamata di blocco sincrono. Al ritorno, il modulo A potrebbe "arricchire" i risultati ottenuti con qualsiasi informazione aggiuntiva e trasferirla ulteriormente al modulo C.

In questo modo non è necessariamente migliore del tuo - ad esempio, carica il modulo A con un ulteriore carico di conoscenza sul modulo C, che non è il caso del tuo approccio. Ecco perché la risposta sopra non si immerge in quale approccio scegliere e quando e invece, semplicemente, si presuppone che il controllo passante da A a B a C sia stato preferito per qualsiasi motivo.