GUIプログラミングは非常に退屈で冗長でつまらない作業だ。しかしそれぐらいならまだいい。今日のGUIライブラリは一種キチガイじみた設計になっている。これがすばらしきOOPの産物なのかとまことに崇拝したい気分である。なるほど僕にはOOPを自由に操る能力が欠けているのかもしれない、あるいは業務には必要な一種の妥協性というのが足りないのかもしれない、しかしどちらにしても時間をかければ解決できると思っていた。つまりは、OOP的にカプセル化されたコンポーネントをある複雑構造で保持し、それの更新あるいは発信をリスナを使って他のカプセル化されたコンポーネントへ反映させることが、OOPに基づいた設計ならば簡単である、あるいは仮に簡単でないにしろ時間をかければ可能であると。しかしそれは幻想にすぎなかったのだ。もう一度言うがこれは僕の能力の欠如なのかもしれないし、もしそうならばむしろうれしいぐらいなのである。なるほどそれらはOOPに基づいてカプセル化されている、それはまことに圧巻するほどに。しかし見てみよ、実際使うにはカプセルを完全なまでに分解せねばならぬではないか。これではカプセル化の恩恵を受けるどこか、ただのガラクタと化したカプセルの外殻が内部へのアクセスをただ妨げるだけで、むしろその矛盾性に設計者は苦しむのである。さて以下のような場合を考えてみよう。コンポーネントAとコンポーネントBは互いに関与すべき機能性を保持しているのだが、それはOOPによればコンポーネント化によって分離されるべきものである。つまりは第三者であるコンポーネントCのようなものを持ってきてコンポーネントAとコンポーネントBの仲介者にしなければならない。さてここでコンポーネントBがコンポーネントAの更新情報を逐次受け取れるようにリスナを設定したいとする。コンポーネントAとコンポーネントBは分離させるべきものなので、仲介者であるコンポーネントCがその仕事を請け負うのだが、さてあなたが注意深い設計者ならばコンポーネントCにその仕事を委託することにおそらくためらうだろう。なぜならそこに本来OOPによって取り除かれるべき依存性が、以前より複雑さをまして存在しているからである。仲介者であるコンポーネントCは依存方向に加えて依存範囲や依存方法などさまざまな情報を持たなければならない。そしてあなたはそれが依存に依存していることに気づかれるだろう。かくしてすばらしきOOPの概念は依存を増やすにまで達した。ここで僕が言いたいのはOOPを真っ当から否定することではない。むしろ閉鎖的にカプセル化されたコンポーネントによる関係性がOOPの概念に矛盾するということが言いたいのだ。それはとくにGUI（のリスナ）プログラミングにおける設計に顕著に現れる。Treeのあるアイテムをダブルクリックしたらあるボタンがフォーカスされる、さてこのような処理をOOPの概念に矛盾することなく実装するにはどのようにしたらよいのか。なるほどMediatorパターンを使って関係を隠蔽し統括するのか。おそらくTreeItemとButtonがフラット構造に配置されているのならOOPは饒舌になるだろう。しかし実際問題、そのようなケースはまれで、大抵の場合は皮肉なことにかかる構造はOOPに基づき複雑にカプセル化されている。どのカプセルも口をあけたがらない。口をあけさせるためにカプセルに特殊な処置をほどこしてMediatorだけを特別に通れるようにする。そしてMediatorはそのわずかに開いた口の隙間を息苦しそうに通り抜けていくのである。あまりに馬鹿げてやしないだろうか。一体他への関与をも閉ざしてしまうカプセル（プライベートなリスナセットを持っている）の用途はどこにあるのだろうか。もちろんOOPは暗黙的に（あるいは明確に述べているかもしれない）依存は決して悪くはないと述べている。それはカプセルがアトム的でないことが許される点からも容易に解せられる。しかし同時にGoFなるものがカプセル化の優位性をこれでもかと語っている。またライブラリ設計者はきまってカプセル化を美学的にとらえてこよなく愛す。一方利用者は美しきカプセル化が織り成す戦慄すべき醜悪さと矛盾性に苦しむのである。なるほどOOPはプログラミングを容易にし簡潔にし明快にする。このことは誰も否定はできない。また以下のことは将来において願わくは現在においても肯定されるべきである。つまり閉鎖的なカプセルというのは何もなしえないということ、そしてむしろその閉鎖性がゆえに開口性に複雑に依存するということである。