If it walks like a duck and quacks like a duck, I would call it a duck.
In duck typing one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. For example, in a non-duck-typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed language, the equivalent function would take an object of any type and call that object's walk and quack methods. If the object does not have the methods that are called then the function signals a run-time error. It is this action of any object having the correct walk and quack methods being accepted by the function that evokes the quotation and hence the name of this form of typing.
Duck typing is aided by habitually not testing for the type of arguments in method and function bodies, relying on documentation, clear code, and testing to ensure correct use. Users of statically typed languages new to dynamically typed languages may want to add such static, (before run-time), type checks which defeats duck typing, constraining the language's dynamism.
Consider the following pseudo-code for a duck typed language:
function calculate(a, b, c) => return (a+b)*c
a = calculate (1, 2, 3)
b = calculate ([1, 2, 3], [4, 5, 6], 2)
c = calculate ('apples ', 'and oranges, ', 3)
In the example, each time the calculate function is called, objects without related inheritance may be used (numbers, lists and strings). As long as the objects support the "+" and "*" methods, the operation will succeed. If translated to Ruby or Python, for example, the result of the code would be:
[1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6]
apples and oranges, apples and oranges, apples and oranges,
Thus, duck typing allows polymorphism without inheritance. The only requirement that function calculate needs in its variables is having the "+" and the "*" methods. The duck test can be seen in the following example (in python). As far as the function in_the_forest is concerned, the object is a duck:
Comparison with other type systems
Comparison with structural type systems
Duck typing is similar to but distinct from structural typing. Structural typing determines type compatibility and equivalence by a type's structure, whereas duck typing determines type compatibility only by that part of a type's structure that is accessed which is determined at run time rather than compile time. The Objective Caml programming language uses a structural type system.
Comparison with interfaces
Interfaces can provide some of the benefits of duck typing but duck typing is distinct in that no explicit interface is defined. For example, if a third party Java library implements a class you are not allowed to modify, you cannot use an instance of the class in place of an interface you've defined yourself. Duck typing would allow this.
Comparison with templates or generic types
Template functions or methods apply the duck test in a static typing context; this brings all the advantages and disadvantages of static versus dynamic type checking in general. Duck typing can also be more flexible in that only the methods actually called at run time need to be implemented, while templates require implementation of all methods that cannot be proven unreachable at compile time.
Examples include the language C++ with templates, Java generics, and various others.
An often cited criticism is this:
One issue with duck typing is that it forces the programmer to have a much wider understanding of the code he or she is working with at any given time. In a strongly and statically typed language that uses type hierarchies and parameter type checking, it's much harder to supply an unexpected object type to a class. For instance, in Python, you could easily create a class called Wine, which expects a class implementing the "press" attribute as an ingredient. However, a class called Trousers might also implement the press() method. With Duck Typing, in order to prevent strange, hard to detect errors, the developer needs to be aware of each potential use of the method "press", even when it's conceptually unrelated to what he or she is working on.
In essence, the problem is that, "if it walks like a duck and quacks like a duck", it could be a dragon doing a duck impersonation. You may not always want to let dragons into a pond, even if they can impersonate a duck.
In practice, the issue is equivalent to not mixing dissimilar objects for duck-typing and is handled almost transparently as part of the knowledge of the codebase required to maintain it.
Alex Martelli made an early (2000) use of the term in a message to the comp.lang.python newsgroup. He also highlighted misunderstanding of the literal duck test, which may indicate that the term was already in use.
In other words, don't check whether it IS-a duck: check whether it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly what subset of duck-like behaviour you need to play your language-games with.
The standard example of duck typing in Python is file-like classes. Classes can implement some or all of the methods of file and can be used where file would normally be used. For example, GzipFile implements a file-like object for accessing gzip-compressed data. cStringIO allows treating a Python string as a file. Sockets and files share many of the same methods as well. However, sockets lack the tell() method and cannot be used everywhere that GzipFile can be used. This shows the flexibility of duck typing: a file-like object can implement only methods it is able to, and consequently it can only be used in situations where it makes sense.
The EAFP principle describes the use of exception handling. For example instead of checking to see if some purportedly Duck-like object has a quack() method (using if hasattr(mallard, "quack"): ...) it's usually preferable to wrap the attempted quacking with exception handling (try: mallard.quack() except (AttributeError, TypeError): print >> sys.stderr "mallard can't quack()"). Advantages of this approach are that it encourages the structured handling of other classes of errors (so, for example, a mute Duck subclass could raise a "QuackException" which can be added to the wrapper without delving more deeply into the logic of the code, and it handles situations where different classes of objects might have naming collisions for incompatible members (for example Mallard the purported medical professional might have a boolean attribute which classifies him as a "quack=True"; an attempt to perform Mallard.quack() would raise a TypeError).
In the more practical examples of classes which implement file-like behavior the use of Python's exception handling facilities is generally preferred for handling a wide variety of I/O errors that can occur due to numerous environmental and operating system issues that are outside of the programmer's control. Here again the "duck typing" exceptions can be caught in their own clauses alongside the OS, I/O or other possible errors without complicated testing and error checking logic.
Duck typing is a fundamental part of Ruby coding. The "pickaxe book" (Programming Ruby), written by Dave Thomas and Andrew Hunt, has a more complete description of duck typing, explaining its perils and benefits.
The web application scripting language ColdFusion allows function arguments to be specified as having type any. For this sort of argument, an arbitrary object can be passed in and method calls are bound dynamically at runtime. If an object does not implement a called method, a runtime exception is thrown which can be caught and handled gracefully. In ColdFusion 8, this can be picked up as a defined event onMissingMethod()rather than through an exception handler. An alternative argument type of WEB-INF.cftags.component restricts the passed argument to be a ColdFusion Component (CFC), which provides better error messages should a non-object be passed in.
The object-oriented programming language Smalltalk does not have type declarations for variables or method arguments and therefore naturally supports duck typing. Classes implementing the same protocol normally belong to the same inheritance hierarchy, but this is not required.
Objective-C, a cross between C and Smalltalk, allows one to declare objects of type 'id' and send any message to them, like Smalltalk. The sender can test an object to see if it responds to a message, the object can decide at the time of the message whether it will respond to it or not, and if the sender sends a message a recipient cannot respond to, an exception is raised. Thus, duck typing is fully supported by Objective-C.