É uma prática ruim para um módulo conter mais informações do que o necessário?

4

Eu só queria pedir sua opinião sobre uma situação que ocorre algumas vezes e que eu não sei qual seria a maneira mais elegante de resolvê-la.

Aqui vai:

Temos o módulo A que lê uma entrada de um banco de dados e envia uma solicitação ao módulo B contendo APENAS as informações do módulo de entrada B precisariam realizar seu trabalho (para manter a modularidade, basta fornecer as informações necessárias - & gt ; o módulo B não tem nada a ver com o restante das informações da entrada de leitura do banco de dados). Agora, depois de terminar o seu trabalho, o módulo B tem que responder a um módulo C se tiver êxito ou falhado. Para fazer isso, o módulo B responde com as informações obtidas do módulo A e alguma variável que significa sucesso ou falha. Agora vem o problema: o módulo C precisa encontrar essa entrada novamente MAS a informação obtida do módulo B não é suficiente para encontrar exatamente a mesma entrada novamente.

Eu não acho que o módulo A dando mais informações ao módulo B que ele não precisa fazer é trabalho, mas que ele poderia devolver ao módulo C seria uma boa prática, porque isso significaria dar alguma informação ao módulo realmente não precisa.

O que você acha?

    
por gekod 20.06.2012 / 15:10
fonte

4 respostas

11

Obter informações de uma parte de um programa para outra é uma batalha constante e quase nunca existe nunca uma solução perfeita.

Eu posso ver quatro soluções possíveis em uma situação como esta:

  1. Basta ir em frente e incluir as informações que C precisa na chamada para B

  2. A chama C com toda a informação e C chama B apenas com a informação que B precisa

  3. Coloque todas as informações em um objeto neutro que B e C possam acessar e deixe que cada uma delas obtenha o que precisam

  4. A chama B com apenas a informação que B precisa, B retorna aprovação / reprovação, A chama C com informação C precisa (introduz dependência de A em C mas remove dependência de B em C)

A "melhor" solução dependerá das circunstâncias que realmente existem em qualquer situação.

    
por 20.06.2012 / 15:23
fonte
6

Concordo com Larry OBrien do que a melhor solução é provavelmente ter uma chamada B, então quando B retorna, A chama C.

Se você realmente não pode fazer isso, eu consideraria ter A passando uma alça opaca para B, que B então passa para C. C pode então passar isso de volta para A para obter acesso às informações necessárias. / p>

Em uma implementação típica, A armazenaria as informações em cache, e o identificador seria realmente algo como um valor de hash ou um índice em uma tabela. Supondo que os dados não são mais necessários após serem passados para C, A também descarregaria os dados do cache depois de passá-los para C em resposta ao acesso por meio do identificador.

    
por 20.06.2012 / 20:22
fonte
6

Se B não pode fazer o seu trabalho (o que inclui dizer C pass / fail) então A não está realmente dando todas as informações de que precisa, é?

Adicione as informações ou deixe de fazer parte do trabalho de B.

    
por 20.06.2012 / 22:33
fonte
1

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

O termo "necessidade" pode ser confuso, a menos que se especifique claramente as necessidades . É verdade que o módulo B não precisa dessas informações para obter o resultado do processamento, mas também é verdade que sem essas informações, seus resultados são inúteis para o módulo C. Nesse sentido, informações adicionais servem a um tipo diferente de necessidade - um integração precisa.

POSA 2 livro apresenta um padrão destinado a atender necessidades semelhantes - Token de conclusão assíncrona :

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)

O livro apresenta um exemplo da vida real para ajudar a entender o padrão: rastreamento de inventário da 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.

Veja, o exemplo acima é bem parecido com o que você descreve. Caras "no meio da cadeia FedEx" podem dizer que não precisam de referência de faturamento, tudo o que precisam saber é endereço de entrega. Mas o remetente pode usá-lo quando precisar ser notificado sobre a conclusão da transação. Essa é uma necessidade tipo integração .

Por uma questão de completude, existe uma abordagem que evita a necessidade de passar a informação de "identificação" para o módulo B. O módulo B poderia retornar seus resultados para o módulo A da chamada de bloqueio síncrona. Ao retornar, o módulo A poderia "enriquecer" os resultados obtidos com qualquer informação adicional e passá-la ainda mais ao módulo C.

Este caminho não é necessariamente melhor que o seu - por exemplo, ele carrega o módulo A com o fardo adicional de saber sobre o módulo C, o que não é o caso em sua abordagem. É por isso que a resposta acima não mergulha em qual abordagem escolher e quando e em vez disso, simplesmente assume que passar o controle de A para B e depois para C tem sido preferido por qualquer motivo.

    
por 21.09.2012 / 09:16
fonte