ことわり
インターネットで久しぶりに本書を薦める文章をみかけたので、家にあったのを再読してみた。しかしー残念ながら、現在市販されている「オブジェクト指向入門 第2版」が手元になく、こちらの初版です（現在のソフトウェア開発の状況からするとちょっと古いかな？という内容も含まれます）。第2版をお持ちでもう読んでないよ、しばらく読む予定がないよ、という方がいらっしゃったら（貸して）ください〜。
Part 1.オブジェクト指向による設計とプログラミングの技法
1.ソフトウェアの品質とは
- ソフトウェア工学の目的は、品質の高いソフトウェアを作る方法を探求することだ。
- ソフトウェアにかかる費用のなかでは保守が大きな部分を占めている。保守で発生する問題は、主に変更が難しいこと、プログラムがデータの物理構造に依存しすぎていることである。
- ソフトウェアの「品質」は、ただ１つの基準でなく、互いに矛盾する可能性のあるものも含めた複数の基準によって判断されるべきだ。
- ソフトウェア品質には「外的品質要因」と「内部品質要因」がある。
- 外的品質要因と内的品質要因を同列に議論してはいけない。
- 最終的に問題になるのは外的品質要因である。ただし、内的品質要因なくして、外的品質要因の達成はありえない。
外的品質要因と内的品質要因
| 分類 | 説明 | 例 |
|---|---|---|
| 外的品質要因 | ユーザーがその有無を確認できる | 要件を満たしているか、スピードは十分か、画面の見やすいか等 |
| 内的品質要因 | 開発者にしか有無を確認できない | モジュール性の高さ、ソフトウェアアーキテクチャの理解のし易さ、コードの読み易さ等 |
外的品質要因の分類
| 分類 | 説明 |
|---|---|
| 正確さ（Correctness） | 要求および仕様に定義された仕事を確実に行う能力 |
| 頑丈さ（Robustness） | 異常な状態においても機能することができる能力（例外処理の網羅や非常事態のフェールソフト等） |
| 拡張性（Extendibility） | 仕様の変更に容易に適応できる能力（具体例：アーキテクチャがシンプルな方が変更に強い、モジュールの独立性が高い程、変更の影響を小範囲に留めることができる、等） |
| 再利用性（Reusability） | ソフトウェアの全体または一部が、どの程度新しいアプリケーション構築に再利用できるか示すもの |
| 互換性（Compatibility） | ソフトウェア相互の組み合わせやすさ |
| 効率性（Efficiency） | ハードウェア資源を効率よく活用していること |
| 携帯性（Portability） | 様々な環境（ハードウェア・ソフトウェア）へのソフトウェアの移植のしやすさ |
| 実証性（Velifiability） | 御作用やエラーの探索をおこなうための準備・用意ができているか |
| 統合性（Integrity） | 御作用やエラーの探索をおこなうための準備・用意ができていること |
| 使い易さ（Ease of use） | 使い方の習得、データの準備、結果の解釈、誤操作によるエラーからの正常な利用へ回復などが簡単であること |
※太字の5個が特に重要
2.モジュール性
- モジュール性は再利用性と拡張性を高めるための肝。
- モジュール性はプログラムだけでなく、仕様と設計においても考慮すべし。
- モジュール化には複数の視点が必要。そのなかにはトップダウンでソフトウェアを分割していく視点と、ボトムアップで導く視点など相反する視点もある。
- モジュール間の通信量と通信形式を制御することが、モジュール性の高いアーキテクチャを実現する第一歩である。
- 情報隠蔽によってインターフェースと実現方法を明確にわけることで、モジュール性の高いアーキテクチャが作られる。
モジュール５つの原則
| 原則 | 内容 |
|---|---|
| 言語としてモジュール単位 | モジュールは使用するプログラミング言語の構文単位に対応していなければならない。 |
| 少ないインターフェース | あるモジュールと対話するモジュールの数は少ない方がよい。 |
| 弱い結びつき | モジュール間で交換する情報量は少ないほうがいい |
| インターフェースの明示 | モジュール間での対話の中身は両方のモジュールから明らかであること |
| 情報隠蔽 | 公にすると宣言されていない限り、そのモジュールに関する情報はそのモジュールのなかに属し、非公開であること |
3.再利用へのアプローチ
- プログラミングには共通のパターンや反復の多い作業だ。パターンの組み合わせは複雑なので、単純にプログラム同士を組み合わせることはできない。
- 再利用にはソフトウェアやエンジニアの界隈だけで解決することのできない経済的、心理的、組織的な問題がある。
- パッケージングはルーチンより優れたカプセル化手法。
- パッケージの柔軟性を拡張する技法が２つあり、「多重定義（overloading）」と「総称性（genericity）」である。「多重定義」は一つ以上の操作を同じ名前で使えるようにすること、「総称性」は型によってパラメタを変えられるようにすること。
- 関連するデータ構造間の共通性を把握する技術とモジュールを分離する技術がいるよ。
4.オブジェクト指向への道
- システムアーキテクチャは機能からもデータからも構築することが出来る。
- 機能よりデータの方が長期的に変化が少ない。
- なので、機能でトップダウンで作った設計は長期間における連続的な変化には適応させづらい。
- オブジェクト指向設計は、操作するオブジェクト（対象）のくらすに基づいたシステム構造を基本とする。
- オブジェクト指向設計でまず目を向けなければいけないのは、「システムがなにを対象とするか」である。「システムが何をするか」ではない。
- 抽象データ型を利用することで、完全な仕様とそうでない仕様を分離でき、オブジェクト指向的なソフトウェアの土台をつくることができる。
- 抽象データ型を「総称的」にすることが可能。抽象データ型は関数・事前条件・公理によって定義される。
- オブジェクト指向設計でのシステムはクラスの集合で構築される。
Part 2.問題と原則
tbw
Part 3.その他の環境におけるオブジェクト指向法の応用
tbw