Como faço para avaliar o equilíbrio entre robustez e código "preguiçoso" no design da API?

6

Lei de Postel:

Be conservative in what you do, be liberal in what you accept from others.

Código "Preguiçoso" (por The Pragmatic Programmer):

Be strict in what you will accept before you begin, and promise as little as possible in return.

Estou desenvolvendo uma estrutura financeira (asset pricing, etc.) para Python. Pergunta: ao projetar a API para a estrutura, que fatores devo considerar quando avalio a troca entre ser rigoroso e ser liberal: entradas?

Exemplo:

Eu tenho o seguinte método que baixa os preços das ações do Yahoo.

def historical_prices(ticker, start=None, end=None, data='d', convert=True):
# Do stuff

Para os argumentos de data ( start & end ), pude:

  • Seja rigoroso e permita apenas uma string do formato ISO AAAA-mm-dd ou
  • Seja liberal e aceite objetos de data e hora, cadeias de caracteres (de formatos especificados), etc.
por MikeRand 30.07.2012 / 16:08
fonte

3 respostas

6

Será mais fácil aceitar a entrada estrita e rejeitar quaisquer outras formas, porque você terá apenas um caso a considerar.

Depende realmente dos requisitos dos seus clientes. Eles precisam de flexibilidade de entrada, ou seja, internacionalização, ou podem trabalhar confortavelmente com um único formato.

    
por 30.07.2012 / 17:02
fonte
5
Seja rigoroso no que você aceita. O liberal no que você aceita, e seja estrito o que você retorna, é baseado em um mundo de agentes independentes, por exemplo servidores SMTP. Se um servidor de e-mail enviar um e-mail com falha e você puder resgatá-lo, isso é melhor do que um erro criptográfico para o remetente do e-mail.

No entanto, quando você está projetando uma API para ser consumida por outros programadores, é uma história diferente. Eles obtêm feedback imediato quando fornecem entrada errada. A outra opção de adivinhar o que eles significam é muito perigosa. Se você aceitar 14-12 em 14 de dezembro e 14 a 10 em 14 de outubro, o que seu programa fará com 10-12? Melhor ser rigoroso, e erro com um deles, assim, seu programa se comportará de maneira previsível, o que é muito mais importante do que ser capaz de aceitar tudo.

    
por 30.07.2012 / 22:05
fonte
-1

Eu codificaria a função principal com um formato específico como entrada. Se houver uma solicitação para adicionar mais formatos, crie uma função para sobrecarregar o nome que converte o objeto de data, etc., em seu formato antes de chamar sua função principal.

    
por 30.07.2012 / 16:55
fonte