レオ・ブローディーの「インターフェースコンポーネント」
LeoBrodieの著書ThinkingForthの85ページで、彼は「インターフェイスコンポーネント」と呼ぶコンポーネントについて説明しています。彼は、標準インターフェースとの違いと、標準インターフェースに対する利点を次のように説明しています。
モジュール間のデータインターフェイスに関しては、従来の知恵では、「インターフェイスは最小限の複雑さで慎重に設計する必要がある」としか言われていません。もちろん、注意を払う理由は、各モジュールがインターフェイスの独自の端を実装する必要があるためです（図3.8）。
これは、冗長なコードの存在を意味します。これまで見てきたように、冗長なコードには少なくとも2つの問題があります。それは、かさばるコードと保守性の低さです。一方のモジュールのインターフェースを変更すると、反対側のモジュールのインターフェースに影響します。
彼はさらに、インターフェースコンポーネントの概念を紹介します。
優れたインターフェース設計にはそれ以上のものがあります。私が「インターフェースコンポーネント」と呼んでいるデザイン要素を紹介させてください。インターフェイスコンポーネントの目的は、2つ以上の他のコンポーネント間のデータインターフェイスを実装し、情報を非表示にすることです（図3.9）。
このパターンは、Javaでプログラミングするときに適用できますか？ Javaのインターフェースは、上記の図3.8に示されているものと似ています。インターフェースコンポーネントオブジェクトが導入された場合、他の2つのオブジェクトとともにすべてインターフェースに準拠する必要があります。定義されていますか？インターフェイスコンポーネントがどのような利点を提供するのかわかりません。
何かご意見は？
プログラミングまたはコンピュータサイエンスのテキストを読むときのルール＃1：「インターフェイス」はJava interfaceコンストラクトを参照しません。（ルール＃1b：テキストが具体的にJava言語について。それでも、保証されません。）
この特定のケースでは、「インターフェイス」は、情報隠蔽、データ抽象化、モジュール性という一般的なコンピュータサイエンスの意味で使用されているように聞こえます。つまり、プライベートな隠された内部実装の詳細と、モジュールを使用するパブリックな方法、つまりインターフェイスの違いです。
テキストが言っていることは、完全にカプセル化された2つのモジュールがある場合でも、それらの2つのモジュールが相互作用することに同意する方法（つまり、それらが相互に提示するインターフェース）は、それらを結合し、さらに悪いことに、変化するということです。それらが相互作用する方法では、両方のモジュールを変更する必要があります。 IOW、相互作用の方法に関する知識は、2つのモジュールに分散しています。
これに対抗する方法は、2つのモジュール間の相互作用を管理する3番目のモジュールを抽出することです。
Brodieが話している「デザイン要素」は、おそらくより現代的/主流の用語ではデザインパターンと呼ばれ、実際には2つのデザインパターンがあります。 Brodieの説明にほぼ一致するGoFブック：
- Bridge Pattern ：抽象化をその実装から切り離します。C++に精通している場合、これはPIMPLの一般化です。熟語。
- Mediator Pattern ：オブジェクトのセットが別のオブジェクトに相互作用する方法をカプセル化します。これを「再-」と呼ぶことができます。相互作用の具体化」、あなたがそうするなら。