Duck Typed

Duck typing in computer programming is an application of the duck test—"If it walks like a duck and it quacks like a duck, then it must be a duck"—to determine whether an object can be used for a particular purpose. With nominative typing, an object is ''of a given type'' if it is declared to be (or if a type's association with the object is inferred through mechanisms such as object inheritance). In duck typing, an object is ''of a given type'' if it has all methods and properties required by that type. Duck typing can be viewed as a usage-based structural equivalence between a given object and the requirements of a type. See structural typing for a further explanation of structural type equivalence.

Example

This is a simple example in Python 3 that demonstrates how any object may be used in any context, up until it is used in a way that it does not support.

class Duck:
def swim(self):
print("Duck swimming")

def fly(self):
print("Duck flying")

class Whale:
def swim(self):
print("Whale swimming")

for animal in uck(), Whale()
animal.swim()
animal.fly()

Output:

Duck swimming
Duck flying
Whale swimming
AttributeError: 'Whale' object has no attribute 'fly'

So, if we assume everything that can swim is a duck because ducks can swim, we will consider a whale to be a duck, but, if we also assume it has to be capable of flying, the whale won’t be considered to be a duck.

In statically typed languages

In some statically typed languages such as Boo and D, class type checking can be specified to occur at run time rather than compile time.

Comparison with other type systems

Structural type systems

Duck typing is similar to, but distinct from, structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.

The TypeScript, Elm, and Python languages support structural typing to varying degrees.

Protocols and interfaces

Protocols and interfaces provide a way to declare, explicitly, that some methods, operators, or behaviors need to be defined (e.g. must have a ''quack()'' method). If a third-party library implements a class that cannot be modified, a client cannot use an instance of it with an interface unknown to that library even if the class does, in fact, satisfy the interface requirements. A common solution to this problem is the Adapter pattern. In contrast, under duck typing, the object would be accepted directly, without the need for an adaptor.

Templates or generic types

Template, or generic 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 runtime'' need to be implemented, while templates require implementations of all methods that ''can not be proven unreachable at compile time''.

In languages like Java, Scala, and Objective-C, reflection can be used to inspect whether objects implement methods or even add necessary methods at runtime.

For example, Java'
MethodHandle API
can be used in this manner.

See also

* Extension method
* UFCS
* Loose coupling
* Monkey patch
* Dynamic programming language

References

{{DEFAULTSORT:Duck Typing
Articles with example pseudocode
Object-oriented programming
Type theory
Articles with example Python (programming language) code