Duck typing
Em programação de computadores com linguagens de programação orientadas a objetos, duck typing é um estilo de tipagem em que os métodos e propriedades de um objeto determinam a semântica válida, em vez de sua herança de uma classe particular ou implementação de uma interface explicita. O nome do conceito refere-se ao teste do pato, atribuído à James Whitcomb Riley, que pode ser expressa como se segue:Quando eu vejo um pássaro que caminha como um pato, nada como um pato e grasna como um pato, eu chamo aquele pássaro de pato.
Imagem: cskk · BY-NC-ND · Openverse
Considere o seguinte pseudocódigo para uma linguagem com suporte duck typing: No exemplo, cada vez que a função calcular é chamada, objetos sem herança relacionada podem ser usados (números, listas e strings). Enquanto os objetos suportarem os métodos "+" e "*", a operação terá sucesso. Se traduzido para o Ruby ou Python, por exemplo, o resultado do código seria:
Imagem: John Markos O'Neill · BY-SA · Openverse
Alex Martelli fez um uso precoce (2000) do termo em uma mensagem para o grupo de notícias comp.lang.python: Em outras palavras, não verifique se ele É um pato: verifique se ele GRASNA como um pato, ANDA como um pato, etc, etc, dependendo exatamente de qual subconjunto de comportamento semelhante a um pato você precisa para jogar com seus jogos de linguagem.
Imagem: reiven · BY-NC-SA · Openverse
Em Python
Duck typing é muito usado em Python, com o exemplo canônico sendo classes semelhantes à arquivo (por exemplo, cStringIO permite que uma string Python seja tratada como um arquivo). De acordo com o princípio de EAFP, em vez de verificar para ver se algum objeto semelhante à Duck supostamente possui um método quack() (usando if hasattr(mallard, "quack"): ...) normalmente é preferível encapsular a tentativa de quack com uma manipulação de exceção apropriada: ou, um uso mais comum do princípio é apenas deixar a exceção "borbulhar", isto é, deixar a exceção ser lançada e deixar qualquer função ou método chamado do código em questão lidar com ela (ou se nenhum lida com ele, deixar a exceção ser lançada para o usuário). Isto dá um melhor feedback em uma saída ruim e evita o mascareamento de bugs.
