従っていれば「オブジェクト指向」の設計をしている。下位のモジュールの再利用は、サブルーチンライブラリという形で確保されている。我々が本当に確保したいのは上位のモジュールの再利用性である。実装の詳細(下位のモジュール)を変更しても、上位のモジュールに影響がないようにしないといけない。適切な適用が欠かせない。あるメニュー項目をクリックしたときに、具体的な処理が行われるとか。メニューのフレームワークが特定の処理に依存しているわけではない。あるクラスがほかのクラスにメッセージを送るようなケースでは、この依存関係の逆転は常に適用できる。シンプルさうんぬんの前に最低限守るべきということ?レイヤーの違うモジュールに関してはこの原則を適用すべきということ。関連性のないインタフェースをまとめないすべてのインタフェースを1つのクラスにまとめてしまわず、関連性のあるインタフェースごとにグループ分けして分離する。インタフェースが太りすぎると、そのインタフェースを変更したとき、多くのサブクラスを再コンパイルしなければいけない。インタフェースを追加するときは、既存のインタフェースを弄るのではなく、新しいインタフェースを追加する方法もある。この方法で追加した新しいインタフェースをクライアントが利用するには、次のように新しいインタフェースを取得することができる。パターンはシンプルだが万能で、様々な目的に利用できる。デバイスの制御に適用すれば、システムの論理的な内部構造とシステムに接続するデバイスの詳細を切り離すことができる。出力先のハードウェアの詳細を意識する必要はない)。オブジェクトを使用することもできる。オブジェクト生成時にその有効性だけをチェックしておき、後からまとめてバッチ処理を行うことができる。処理をサポートできる。実行時に以前の状態を覚えてスタックに積まれる(当然、操作対象となるオブジェクトの参照も覚えておく)。メソッドにより以前の状態に戻される。つのスレッドでシーケンシャルに行われるため、スタック領域を節約しなければならないようなメモリの限られたシステムでメリットが大きい。スレッドを分離するパターン。解決しようとしているのは、複数スレッドからの共有オブジェクトへのアクセスが引き起こす下記のような課題。共有オブジェクトにおけるメソッド呼び出しが実行されるときに、全体のスレッドがブロックされてしまうのを防ぎたい。複数スレッドからの共有オブジェクトへのアクセスはできるだけシンプルにしたい。かけなければならないのは複雑だ。アプリケーションは透過的に並列性を利用するように設計されるべきだ。←▼これの意図がよくわからない。オブジェクトに変換されるので、普通のメソッド呼び出しと同じようになる。全体のフローの概要は以下の通り。経由で共有オブジェクトのメソッドを呼び出す。