kmizu:これはオブジェクト指向を使うソフトウェアエンジニアの間でも議論になるところですが、個人的にはおっしゃる通り「派生元の実装を再利用して別の型を提供する」こと自体に難しい部分があると思います。著名なオブジェクト指向プログラミングの書籍で「（実装の）継承より委譲を検討する」ということが書かれているのはそういったことを踏まえてだと思います。 　派生元の実装を再利用して別の型を提供する、の典型的なユースケースがTemplate Methodパターンですが、欠点としてスーパークラスのメソッドの実装（事前/事後条件ではなく）をある程度把握しておかないといけないということがあります。なので、質問者様の懸念はもっともなのですが現実的には便利な局面も多々あるのは確かです。Rubyは静的な型を持ちませんが、Enumerableモジュールを継承（include）してeachメソッドだけを実装することで、他の全てのメソッドが使えます。このアプローチは結構うまく行っているように感じます。何故なのかと先程考えてみたのですが、eachメソッドを使って実装されている他の大部分のメソッドは適切に事前/事後条件を満たすように設計されており、かつ、eachメソッドの実装にあたって意識すべき事後条件がほとんどないため、うまく行くのではないかという気がします。 Java 8以降にあるインタフェースのデフォルト実装を利用したライブラリ、たとえば、java.util.Listに追加されたいくつかのメソッドのデフォルト実装についても似た利点があると感じます。デフォルト実装が使う抽象メソッドについては事前/事後/不変条件だけを意識すれば良くて、デフォルト実装自体をオーバーライドしないからデフォルト実装の事後条件などについては意識する必要がないので比較的うまく行くのかなというのが個人的な所感です。 　ただ、プログラミング言語の基本ライブラリで、かつ設計者が非常に慎重に基底クラスを設計した場合にのみ有効というのが経験則で、アプリケーションコードでは「派生元の実装を再利用して別の型を提供する」というアプローチはとると、後々後悔することになることも多いなというのが正直なところです。