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:
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.
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.
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.
Tags api-design api python