いつ読んでも内容はすばらしいのですが、読んだはずなのに覚えていない自分が情けなくなってきます。気に入った部分を未来の自分へ宛てて残そうと思います。
情報隠蔽の価値
「何を隠蔽するべきか」と自問する習慣を付けよう。多くの難解な設計問題が目の前で解決されるのを見て、驚くことになるだろう。
確かに、どの情報を隠蔽するのかということは抽象化を行う際に必ず通るプロセスですよね。APIをラップするときに、なぜラップするかはケースバイケースでしょうが、不必要な情報をそぎ落とすことで使いやすくシンプルな設計にしたいからということは根底に必ずあると思います。つまり、複雑な事象を扱う場合、できるだけ関心事を減らす工夫が必要なわけで、その工夫の一つとして情報の隠蔽が有効ということになるのだと思います。
さまざまな度合いの変更を予測する
変更の可能性のある領域を特定するよい方法は、まずプログラムからユーザーの役に立つと思われる最小のサブセットを抜き出すことである。これはシステムの革新となる部分であり、変更される可能性が低い。
これはひとことで言い表すならば事象の根本を押さえるということになると思います。個々の事象をそれぞれ個別に対応するよりも、個々の事象がどこかでつながっていないかを見つけ、共通点から根本的な事象を把握する。その根本的な事象が、結果的にユーザーのニーズであったり必要とするシステムの仕組みだったりすることがよくあります。また、そのニーズや仕組みは他のものほど変更されることはないものですね。
疎結合の維持
クラスやルーチンは、複雑さを軽減するときに真っ先に思い浮かぶツールである。それらを使って作業を単純化できないとしたら、それらは目的を果たしていない。
プログラムがスパゲッティになっているケースで多いことは、多くの事柄を一つのメソッドなりルーチンなりで行いすぎということがあります。ただ計算を行うだけのはずが、メソッドの中で計算結果を別なオブジェクトに渡して、そのオブジェクトで値を変更して、その値によって処理が分岐して…と、プログラムを書いた人が思いついた内容をそのままコーディングしているような内容が結構あります。本来便利な道具が使い方を間違えることにより不便になるのは残念なことです。
できるだけ役割を分けること、役割を持っている人に責任を委譲することを心がけることで幾分解消するのかなぁと思います。
