伊藤です。

てゆうか 話の半分の部分は
ポインセチアは赤い、バラの花も赤い。
象の鼻は巻きつく、猿の尾も巻きつく。
親クラスや全体は異なるが使用する
[部分の性質]が一致する物は[その状況で同一視]。
FILE->IO のクラスを使っているけれど
全体が完全一致でないとダメではない。
言語の機構は全体の一致を見るのしか入っていない。
この意味ギャップでしょう。
(人インスタンスは同じだが恋愛インターフェイスと結婚インターフェイスは
違う。??)

雑誌の発行者と読者の関係に類似している。
読者の好みは多様だが、対応できるだけ多種類を発行できない。
ある程度くくらないと。 連載の部分、グラビアページの部分しか
見なくとも雑誌全体を購入する。
雑誌「人の手」の読者に「猫の手」を読ませるようにするには
偽の表紙をかぶせる事になる。「人の手」の目次はあるが大部分の
ページは白紙で「先生できません」関数で埋まっている。
対応する「猫の手」メソッドがあるとろこのみ印刷してある。

なんだ、アダプターパターンじゃないか、白紙ページが多いけど
不良資産じゃないよ、放置する、で納得。
安心して眠ってしまってはレベルが低いかな?

この線でゆくとXをYに見せかける中間調整のチョットいいクラス
が多量に必要になる?そうならないようにクラス階層を綺麗にする
努力があるとしても。必要だからあるのだと開き直ればそれまでですが。

対策A
アダプタクラスの手軽な生成の方向、あるいは自動生成したり
アダプタクラスがあること自体を見えなくする方向。
ファイル、Clipboard、Socket、ウィンドウハンドルを投げ込むと
InputTextStream を作って返してくれるようなエンジン。
個々のメソッドを比較して使う方から見て同じなら結びつける。
どうやって?
メソッドの形式仕様を比較する、イカンイカン、そんな話に乗ったら
腎臓まで取られてしまう。
言語の仕組みでは名前が一致なら中身も同等しかないから、
人#concat と猫#append は結合できないし、ここで思考停止。
分散エージェントと交渉するのにも近くなる。

対策B
使わない物が大量にあるのは変だと思う方向。
使用者側でFILE->IO のこの部分しか使いません宣言(マスクビット)
をして、オブジェクトを受けたらメソッドを調べて使える物を列挙する。
一致したらそのまま使う。偽表紙をかぶせなくてよい?
メソッド1本毎にどれと同じかというようなDBが必要かもしれない。
作れるか?それともメソッドを最初に書くときに既知のクラスの
どのメソッドと互換性があるかというような指定を書いておく。
書きにくくなる一方だ、デバッグできない。

やっぱり、解らなければソースを読めの地獄から脱出できないのか

それなら支援ツール、使用メソッドセットを指定すると類似の
状況を調べてくれてアダプタクラスを作りやすくする。

クラスを使うときはたいてい部分しか使わないを支援する何かが...

●