ブラウザは個々の開発者のスクリプトなんて知ったこっちゃないんですよ。ありのままボタンクリックシグナルを発するだけ。アプリケーションがそれを観測して動き始める。それが Observer パターンですよ。
通常は、詳しいことは知らないけどより UI に近い側のコードが、アプリケーションのさらに深い処理の詳細実装を呼び出しますよね。ところが、UI の最末端であるブラウザのボタンコンポーネントは、それぞれのサービスのアプリケーションコードよりはるか前に実装され、完成しています。W3C の求めるとおりに作られたブラウザの UI 部品は、各種の SNS や EC サイトの機能なんて知るよしもありません。
HTML 上のボタンは、ただただ、クリックされましたよというシグナルを発するだけ。後から来たアプリケーション側が、そのシグナルを観測し、アプリケーション機能をトリガーする。というような、イベント発生とそのリスニングで DIP を実現するのが Observer (観測者) パターンです。
くるみクンは何もコールせず、たんに、わからないことを不思議だなぁとつぶやくだけ。もしそれを誰も観測していなければ、何も起きず、わからない部分をそういうもんなんだと流して、理解せずに進んじゃいます。
でも、めもりーちゃんチームはすごく後輩思い(説明したがり)なので、彼女の発した違和感をキャッチし、どのようにして、先に実装がフリーズしているイベント発生元が、後に実装されたビジネスロジックを起動できるのかを教えてくれます。学びある職場ですね。すばらしい。
実装としては、主オブジェクト自身、またはそのオブジェクトが持っているイベントマネージャーに、イベントリスナーインターフェースを実装したインスタンスを Observer (観測者) として登録しておき、イベントが起きればその観測者のメソッドに委譲するという仕組みです。つまり、動的に差し替えられる DIP です。
Observer パターンは、ブラウザとユーザー JavaScript のような極端な場合だけで使うものというわけではありません。先に安定した主機能に対して、カスタマイズとして後から処理を挟み込みたい場合などに、とても有用です。
画面がなくても、たとえば何かのフレームワークで、当初想定された処理しかしない部分に、追加でログを残したり、汚いユーザー入力を正規化したり、あるいは、割り込みの結果によっては続く処理を中断したりなど、用途はとても多岐に渡りますす。
Observer はコードの安定度に偏りがあるとき、ごくごく普通にあらわれるパターンです。身の回りのコードや顧客ニーズをよく観察してみると、このパターンの方が都合良かったかも、と発見できるかもしれません。
ぜひみなさんのプロダクションコードでも、Observer による疎結合化で DIP したらうまく行きそうな場所を探してみてください。