The problem with interfaces is that you have to reimplement all the code for the basic functionality in every class. Scala-like traits, which are basically interfaces with optional implementation, should help here.
Also, if you're using a flat type hierarchy where classes never inherit, but only extend interfaces, you're better of using a different language which natively supports a structural typing style, such as Go, OCaml, or Objective C.
In the Moose / Perl 6 world, we use roles for this. (I know the idea is borrowed from elsewhere, but I don't know where.) As a Perl 6 programmer, I have almost completely given up on traditional inheritance, because roles capture everything I want from inheritance with greater robustness.
To be fair to original article, this does mean I'm doing my best to avoid type hierarchies...
It was a combination of dissatisfaction with multiple inheritance (see Perl 5, C++), interfaces (see Java), and mixins (see Perl 5, Ruby), as well as an acknowledgement that aspects (see Java) and multimethods (see Common Lisp) solve part of the problem well and part of the problem poorly.
Then Allison and I saw Dr. Black present the Smalltalk traits paper and she realized that their formalism was exactly what I'd been talking about informally, so we borrowed that instead.
Roles have specific composition rules which forbid name collisions; there's no last-in wins rule. Roles also provide type allomorphism which is much less ambiguous than duck typing.
Just use polymorphic associations (weak linking) wherever you want to enable code reuse and the implementation is not tightly linked to the class hierarchy. It is about how you think in terms of OO.
Also, if you're using a flat type hierarchy where classes never inherit, but only extend interfaces, you're better of using a different language which natively supports a structural typing style, such as Go, OCaml, or Objective C.