Structural typing (sometimes referred to as "duck typing") has a few problems that make me unconvinced about the benefits.
First of all, I agree that the accidental argument is not very convincing (two developers writing a method Launch(), one that launches a football and another that launches nuclear missiles).
However, we lose two important things with implicit interfaces:
- Code readability. It becomes much harder for a human to interpret what types are actually implemented.
- More importantly, it severely limits the tooling available since the compiler has a lot less knowledge about the types you are dealing with. Automatic refactorings are all but impossible with structural typing.
Overall, I really don't see the harm in saying explicitly "My type is called Account and it implements Serializable and Entity" as opposed to me having to guess by reading all its methods and also having to remember which methods are necessary to be an Entity or a Serializable.
Duck typing and structural typing are not the same thing. In structural typing you are still making assertions about the type, in duck typing you are deliberately avoiding them. The opposite of structural typing is nominal typing, where in types are named and explicitly associated with the objects they represent.
Particularly, this is extremely wrong when talking about structural typing:
> - More importantly, it severely limits the tooling available since the compiler has a lot less knowledge about the types you are dealing with. Automatic refactorings are all but impossible with structural typing.
The compiler has as much information in structural typing as it does in nominal typing. The type of an object is determined at compile time either way, it's just that in structural typing Account implements Serializable and Entity because a subset of its methods match the definitions of Serializable and Entity, not because you said it does.
First of all, I agree that the accidental argument is not very convincing (two developers writing a method Launch(), one that launches a football and another that launches nuclear missiles).
However, we lose two important things with implicit interfaces:
- Code readability. It becomes much harder for a human to interpret what types are actually implemented.
- More importantly, it severely limits the tooling available since the compiler has a lot less knowledge about the types you are dealing with. Automatic refactorings are all but impossible with structural typing.
Overall, I really don't see the harm in saying explicitly "My type is called Account and it implements Serializable and Entity" as opposed to me having to guess by reading all its methods and also having to remember which methods are necessary to be an Entity or a Serializable.