É considerado um antipadrão para ler o STDIN de uma biblioteca?

Enquanto escrevia uma biblioteca para um projeto grande em que estou trabalhando, surgiu um problema que exigia que um token fosse enviado para um endereço de e-mail e depois passado de volta para o código, onde poderia ser usado para uso posterior.

Meu colega diz para ler apenas o STDIN (usando Python:) code = input("Enter code: ")e depois fazer com que um usuário o passe, no entanto, para mim, isso parece uma prática ruim, pois a biblioteca pode (neste caso definitivamente será) ser usada em uma tarefa em segundo plano em um servidor .

Fiquei me perguntando se isso era ou não considerado antipadrão ou não.

Como orientação geral, as bibliotecas devem ser totalmente desconectadas do ambiente. Isso significa que eles não devem executar operações em fluxos padrão, em arquivos específicos ou ter qualquer expectativa sobre o ambiente ou o contexto em que são usados.

Obviamente, há exceções a essa regra, mas deve haver uma boa razão para isso. No caso de usar stdin, não consigo encontrar nenhum motivo (a menos que sua biblioteca realmente forneça rotinas para leitura do stdin, como std::cindo C ++). Além disso, pegar os fluxos de E / S de um parâmetro em vez de codificá-los adiciona tanta flexibilidade que não vale a pena não fazê-lo.

Eu consideraria isso não necessariamente um antipadrão, apenas uma biblioteca mal projetada. Deve ser trivial solicitar uma string como parâmetro de método, onde a entrada pode ser passada diretamente.

Se isso não se encaixa nesse uso, um parâmetro de método pode ser um fluxo, com STDIN passado para o método.

Se isso não se encaixa nesse uso, a biblioteca não é flexível o suficiente.

Talvez considere ter em sua biblioteca a capacidade de definir um retorno de chamada para uma função fornecida pelo usuário que lerá as entradas de qualquer lugar e, em seguida, retorne o valor apropriado para qualquer parte da biblioteca que esteja usando essa função.

Se ler do stdin, significa que gostaria de assumir a propriedade do stdin no nível do programa. Provavelmente não é compatível com nenhuma outra biblioteca que leia a partir de stdin, protocolo menos específico de como eles compartilham o uso. Pelo menos no meu próprio glossário pessoal, isso tornaria a biblioteca uma estrutura , o que é uma troca cara.

Mas, nesse caso, a biblioteca provavelmente deve apenas usar um descritor de arquivo de entrada.

A resposta de @ Paul92 é uma boa discussão geral, mas eu gostaria de oferecer uma possível solução limpa (ish) para isso:

Como uma biblioteca, esse código precisa ser adaptável a qualquer ambiente de tempo de execução; portanto, você não pode realmente solicitar STDINalguns dados cruciais. Por um lado, os usuários da sua biblioteca podem não ter o stdin disponível por vários motivos. Em vez disso, convém usar alguma forma de padrão de estratégia para personalizar como o token deve ser recuperado.

No Python, provavelmente a melhor opção é passar a estratégia de busca de token como um parâmetro de função. Algo parecido:

def stdin_prompt():
    return input("Enter code: ")

def my_library_function(arg1, arg2, ... argn, token_provider = stdin_prompt):
    ...
    token = token_provider()
    ...
    return stuff

# somewhere in the user code
stuff = my_library_function(a1, a2, ... an, lambda: "123456")

Pense nisso assim. O token que você precisa é um argumento para a função de biblioteca. Como o valor do token pode não ser conhecido estaticamente no site da chamada, você não pode realmente solicitar o valor como argumento. Em vez disso, o chamador deve fornecer uma função que será responsável por fornecer o token quando chamado.

Toda a responsabilidade de fornecer a mecânica exata do token agora é externalizada a partir da função de biblioteca. O consumidor da função agora é responsável por adquirir o token por quaisquer meios disponíveis em tempo de execução. Pode perguntar ao STDIN, mas também pode funcionar como um gateway de email, aguardar a mensagem aparecer na caixa de entrada, ler, extrair o token e automatizar completamente o processo. Pode ser um diálogo da GUI ou um formulário baseado na Web. Qualquer coisa realmente - todas as opções estão agora nas mãos do consumidor da biblioteca.