名著としての誉れが高い Bertrand Meyer著「オブジェクト指向入門」（第１版）が、本棚の肥しになりかけていたので、頑張って読むことにしました。といっても、たんに読むだけではすぐ忘れること請け合いなので、簡単な要約を作っていきます。
今回の範囲は、第１章「ソフトウェアの品質とは」と、第２章「モジュール性」です。
「オブジェクト指向プログラミング」という言葉がバズワード化して消費されていってしまった（ように見える）のは「何のためにそれがあるのか？」がいまいち共有されていなかったからではないかと私は考えています。
その意味で、好ましいソフトウェアとはどのようなものか？ 何を目指すべきか？ を議論するこの２章は重要です。
１章 ソフトウェアの品質とは
１．１ 外的品質要因と内的品質要因
実行速度や使いやすさのように、ユーザから見える品質を外的品質要因という。対して、プログラムがきれいかどうかといった、ユーザから見えない品質を内的品質要因という。
ソフトウェアが成功したかを評価する上で、最終的に問題になるのは、外的品質要因だけだ。しかし、内的品質要因こそが、外的品質要因を満足させるためのカギだ。
この本の大部分は、内的品質要員について述べることになる。ただし、内的品質要因は外的品質要因を実現するためにあることを忘れてはいけない。
１．２ 外的品質要因
外的品質要因のうち、最も重要なものを紹介する。
１．２．１ 正確さ
正確さとはソフトウェア製品が要求および仕様によって定義された通りに確実に仕事を行う能力である。
１．２．２ 頑丈さ
頑丈さとは異常な状態においても機能するソフトウェアシステムの能力である。
正確さを目指すより、頑丈さを目指すことのほうがずっと曖昧だ。頑丈さは仕様にって明確にされていない場合の動作を問題にする。
１．２．３ 拡張性
拡張性とはソフトウェア製品が仕様の変更に容易に適応できる能力である。
拡張性を向上させるカギは次の２つ。
・簡明さ：簡単なアーキテクチャのほうが変更に対応しやすい。
・非集中性：モジュールが独立していれば、変更が発生した場合の影響を小さくできる。
１．２．４ 再利用性
再利用性とは、あるソフトウェア製品の全体または一部分が、どの程度新しいアプリケーション構築に再利用できるかを示すものである。
１．２．５ 互換性
互換性とは、あるソフトウェア製品相互の組み合わせやすさである。
例えば、バイナリファイルよりもテキストファイルを使おう、という考え方。
１．３ ソフトウェアの保守について
統計によれば、ソフトウェアにかかる費用の70%は保守に費やされている。
ソフトウェアの保守が困難な原因は、ソフトウェア製品が変更を受け入れにくくなっていること、プログラムがデータの物理構造に依存しすぎていることである。
１．４ ５大要因
先に述べた５大要因は、２つのグループに分類される。
拡張性、再利用性、互換性：
柔軟で分散化された設計を生み出す技術を必要とする。
正確さ、頑丈さ：
要求および制約の詳細な仕様に基づいて行われる。
２章 モジュール性
拡張性、再利用性、互換性を達成するには、「ソフトウェアのモジュール性を高めなければならない」。
しかし、モジュール性とはなんだ？
モジュール性が高いということは何を意味するかを評価するために、５つの「基準」と５つの「原則」を紹介する。
２．１ ５つの基準
モジュール性という観点から、設計手法を評価するための基準を紹介する。
２．１．１ モジュールの分解しやすさ
１つの問題を互いに独立した小さな問題に分割することができるかどうか？ という基準。
分解によって作られた小問題を、それぞれ独立した仕事として異なる人に割り振ることが出来なければいけない。
２．１．２ モジュールの組み合わせやすさ
最初の環境とは全く違った環境においても自由にソフトウェアの要素を組み合わせて新しいシステムを作ることができるか？ という基準。
２．１．３ モジュールのわかりやすさ
モジュール１個１個を取り出して個別に見てもわかりやすいかどうか？ という基準。
いくつかのモジュールがあって、それらが特定の順序で実行されなければ正しく動作しない、といった場合、個別のモジュールを取り出しても理解できなくなってしまう。
２．１．４ モジュールの連続性
小さな変更を加えた場合、その変更がわずかなモジュールにとどまるか？ という基準。
数字定数や文字定数を使わず、シンボル定数を使うなどは賢明な方法だ。
２．１．５ モジュールの保護性
あるモジュール内で発生した異常条件の影響が、わずかなモジュールにとどまるか？ という基準。
例外処理はモジュールの連続性を損なう傾向がある。第７章では、保護性を損なわない規則的な例外処理のメカニズムについて考える。
２．２ ５つの原則
モジュール性を確保するために守らなければならない原則を紹介する。
２．２．１ 言語としてのモジュール単位
モジュールは使用する言語の構文単位に対応していなければならない。
２．２．２ 少ないインターフェース
モジュールはできるだけ少ないモジュールと対話すべきである。
２．２．３ 小さいインターフェース（弱い結び付き）
２つの対話するモジュールがある場合、それらが交換する情報の量はできる限り少なくなければならない。
２．２．４ 明示的なインターフェース
モジュールＡとＢが対話する場合、その対話は必ずＡあるいはＢ、もしくはその両方のテキストから明らかにならなければならない。
２．２．５ 情報隠ぺい
特に公にすると宣言されていない限り、モジュールに関する情報は全てそのモジュールのみに属する非公開の情報である。
機能と実現方法とを分離する。実現方法が変わっても、そのモジュールを使えなければならない。
２．３ 解放/閉鎖原則
・モジュールがまだ拡張可能ならば、そのモジュールは解放されているという。
・モジュールが他のモジュールから使用できるならば、そのモジュールは閉鎖されているという。
モジュールの分解しやすさを満足させるには、モジュールは開放的であると同時に閉鎖的でなければならない。つまり、モジュールに対する機能追加などの拡張はいつでも可能だが、拡張してもそれまでに書かれた部分は変更しなくてもすむといったことが求められる。
古典的な設計アプローチやプログラミング方法では、開かれていると同時に閉じているモジュールを書くことは不可能である。このジレンマを解決できるのは、オブジェクト指向的な手法によって得られる継承だけである。