tipificación de pato y el concepto

Question

interfaz (Java) que acabo de leer el artículo de Wikipedia sobre duck typing, y siento que me olvido de un punto importante sobre el concepto de interfaz Solía ​​en Java:

"When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck." 


class Duck: 
    def quack(self): 
     print("Quaaaaaack!") 
    def feathers(self): 
     print("The duck has white and gray feathers.") 
    def swim(self): 
     print("Swim seamlessly in the water") 

class Person: 
    def quack(self): 
     print("The person imitates a duck.") 
    def feathers(self): 
     print("The person takes a feather from the ground and shows it.") 
    def name(self): 
     print("John Smith") 

def in_the_forest(duck): 
    duck.quack() 
    duck.feathers() 

def game(): 
    donald = Duck() 
    john = Person() 
    in_the_forest(donald) 
    in_the_forest(john) 

game() 

¿y si, en in_the_forest, escribo:

• lo hace quack como un pato? sí
• ¿tiene pato feathers? sí
• genial, es un pato que tenemos!

y posterior, porque sé que es un pato, lo quiero swim? john se hundirá!

No quiero que mi aplicación falle (aleatoriamente) en el medio de su proceso solo porque John fingió ser un pato, pero supongo que no sería una buena idea verificar cada atributo del objeto cuando lo recibo ...?

Answer 1

Duck typing no se trata realmente de verificar si las cosas que necesita están allí y luego usarlas. Duck typing se trata solo de usar lo que necesita.

La función in_the_forest fue escrita por un desarrollador que estaba pensando en patos. Fue diseñado para operar en un Duck. Un Duck puede quack y feathers, por lo que el codificador usó esas características para realizar el trabajo. En este caso, el hecho de que un Duck también puede ser swim no se usó, y no fue necesario.

En un lenguaje estático como Java, in_the_forest habría sido declarado para tomar un Duck. Cuando el codificador descubrió más tarde que tenían un Person (que también podría ser quack y feathers) y quería reutilizar la función, no tuvieron suerte. ¿Es Person una subclase de Duck? No, eso no parece apropiado. ¿Hay una interfaz QuacksAndFeathers? Tal vez, si tenemos suerte. De lo contrario, tendremos que hacer uno, vaya a modificar Duck para implementarlo, y modifique in_the_forest para tomar un QuacksAndFeathers en lugar de un Duck. Esto puede ser imposible si Duck está en una biblioteca externa.

En Python, acaba de pasar a su Persona al in_the_forest y funciona.Porque resulta que in_the_forest no necesita un Duck, solo necesita un objeto "parecido a un pato", y en este caso la Persona es lo suficientemente parecida a un pato.

game embargo, necesita una definición diferente de "parecida a un pato", que es un poco más fuerte. Aquí, John Smith no tiene suerte.

Ahora, es cierto que Java habría detectado este error en tiempo de compilación y Python no. Eso puede verse como una desventaja. El argumento del contador pro-dynamic-typing es decir que cualquier cuerpo sustancial de código que escriba contendrá siempre errores que el compilador no puede capturar (y para ser honesto, Java ni siquiera es un ejemplo particularmente bueno de un compilador con fuerte controles estáticos para atrapar muchos errores). Entonces debes probar tu código para encontrar esos errores. Y si está probando esos errores, encontrará trivialmente errores donde pasó un Person a una función que necesita un Duck. Dado que, dice el mecanógrafo dinámico, un lenguaje que lo tienta a no prueba porque encuentra algunos de sus errores triviales es en realidad un malo cosa. Y además de eso, le impide hacer algunas cosas realmente útiles, como reutilizar la función in_the_forest en un Person.

Personalmente estoy dividido en dos direcciones. Realmente me gusta Python con su tipado dinámico flexible. Y realmente me gusta Haskell y Mercury por sus potentes sistemas de tipo estático. No soy muy fanático de Java o C++; en mi opinión, tienen todos los bits malos de tipeo estático con algunos de los bits buenos.

Answer 2

No se puede hablar en otros idiomas, pero en python se ha introducido recientemente (v2.6) el Abstract Base Classes (ABC) module.

Si lee los motivos de su introducción (PEP 3119) rápidamente se dará cuenta de que parte del motivo fue "salvar a John de una muerte segura" o, para facilitar el control del hecho cuando programa en un interfaz, todos los métodos de interfaz estarán allí. Desde el PEP vinculado:

ABC son simplemente clases de Python que se añaden al árbol de herencia de un objeto para señalar ciertas características de que se oponen a un inspector externo. Las pruebas se realizan utilizando isinstance() y la presencia de un ABC particular significa que la prueba ha pasado. Además, los ABC definen un conjunto mínimo de métodos que establecen el comportamiento característico del tipo. El código que discrimina objetos basados ​​en en su tipo ABC puede confiar en que esos métodos siempre estarán presentes.

En general, puede aplicar el mismo patrón para su propio código. Por ejemplo: puede crear una clase BasePlugin con todos los métodos necesarios para que un complemento funcione, y luego puede crear varios complementos diferentes subclassing. Dependiendo de si cada plugin debe o puede definidos por dichos métodos, se puede definir BasePlugin métodos para pasar en silencio (plugins puede definir los métodos) o para lanzar una excepción (plugins deben definir los métodos/anular el BasePlugin uno).

EDIT: En el hilo de comentarios a continuación, se me ha sugerido incluir en la respuesta de este poco de discusión:

Este tipo de características - por lo menos en Python - no se aplican para el El programador humano (Python nunca silencia un error, por lo que ya hay muchos comentarios), sino por la propia capacidad de introspección de Python (lo que facilita la escritura de carga dinámica, código de metaprogramación, etc.). En otras palabras: sé que John no puede volar ... ¡pero quiero que el intérprete de Python también lo sepa! :)

Answer 3

Yo no quiero que mi aplicación se bloquee (al azar) en medio de su proceso sólo porque John fingió ser un pato, pero supongo que no sería una buena idea para comprobar cada uno de los atributos del objeto cuando lo recibo ...?

Esa es una cuestión de tipado dinámico en general. En un lenguaje estáticamente tipado como Java, el compilador comprueba en tiempo de compilación si Person implementa IDuck o no. En un lenguaje de tipado dinámico como Python, se obtiene un error en tiempo de ejecución si Person pierde alguna función de pato en particular (como swim). Para citar otro artículo de Wikipedia ("Type system", Section "Dynamic Typing"):

tipado dinámico puede dar lugar a errores de tipo en tiempo de ejecución, es decir, en tiempo de ejecución, un valor puede tener un tipo inesperado, y se aplica una operación sin sentido para ese tipo. Dichos errores pueden ocurrir mucho después del lugar donde se cometió el error de programación, es decir, el lugar donde el tipo incorrecto de datos pasó a un lugar que no debería tener. Esto puede hacer que el error sea difícil de localizar.

La tipada dinámica tiene sus inconvenientes (usted ha mencionado uno) y sus ventajas. Se puede encontrar una breve comparación en otra sección del artículo del sistema Type en Wikipedia: Static and dynamic type checking in practice.