【読書メモ】オブジェクト指向入門 第二版 原則・コンセプト

前書き

個人的備忘録です。
素晴らしい本でした！
が、ボリュームが多すぎて読み返すのが大変なので抜粋メモです。
オブジェクト指向は一言で言えるものではなく感覚的なものだと思うので、曼荼羅方式です。

メモ

1. 良いインターフェース設計者はもっと慎重な方針に従っている。ユーザーについての前提条件をできるだけ作らないのだ。
2. 良いソフトウェアは少数の強力な概念を基礎に作られている。特殊な機能が数多く用意されている場合でも、それらの機能は全てこれらの基本的な概念で説明できるものでなければならない。
3. オブジェクト指向では、全てのモジュールがそれ自身のデータ構造の初期化の責任を持つ。
4. プロジェクトの進行に伴い、要求はほとんど必ずと言って良いほど変更される。小さな変更による影響は、システムの構造そのものではなく、構造の中の個々のモジュールで吸収されるべきであることを連続性は意味している。
5. ソフトウェアテキストはそのままドキュメントにするには詳しすぎる場合が多い（そのために情報隠蔽がある）。その代わりに、モジュールの中にドキュメントを含めるべきなのである。
6. 単一責任選択の原則：ソフトウェアシステムが選択肢を提供しなければならない時、そのシステムの中の一つのモジュールだけがその選択肢の全てを把握すべきである。
7. 繰り返しの様子を分析すると、プログラマは同じようなことを何度も繰り返す傾向があるが、全く同じことをしているのではないことが分かる。
8. 再利用性について説明しているところではほとんど必ず拡張性についても考慮しているのは偶然ではない。
9. トップダウン設計のスタート地点として明白に見えるもの、すなわち、新たな開発は1つの具体的な機能要求を満たすという見方が疑わしい。現実のシステムにはトップが存在しない、
10. ユーザーインターフェースはシステムの構成要素の一つに過ぎない。多くの場合、最初から正しいものを作ることの難しさを考えただけでも、ユーザインターフェースは最も不安定な要素の一つである。
11. 実のところ、トップダウン設計という概念そのものが再利用性の逆を意味している。再利用性のための設計は、できる限り一般的な要素を作り、それを組み合わせてシステムを作ることを意味する。これはボトムアップの過程であり、「問題」の定義に始まり、詳細化の繰り返しによって解決手段を求めるトップダウンという概念の反対である。
12. システムが扱うオブジェクトの型はモジュールの選択を助け、連続性という目標を満たすようなその安定した存在の候補としてより有望である。前に例として登場した給与支払いシステムに何が起ころうと、従業員、賃金表、社内規定、労働時間、給料小切手を表すオブジェクトを操作することは恐らく変わりがないだろう。
13. オブジェクトのモットー：システムが何をするかを最初に考えるな。その対象を考えよ！
14. 定説では、厳密に限定する要求書に書かれたシステムの機能を実現することがシステム構築として考えられる傾向にある。しかし、最初にデータをみてシステムが果たすべき目標を忘れるという単純な考えが再利用性と拡張性の鍵を握っているのである。
15. 抽象データ型は一つのオブジェクトではなく、オブジェクトの集合の一つである。
16. 定義：クラス：クラスは（部分的であっても良い）、実装を伴う抽象データ型である。
17. p1.x この記述は、この記述によりオブジェクトのフィールドへのアクセスが発生するか、ルーチンの実行が発生するかに関わらず常に変わらない。
18. システムの実行：オブジェクト指向ではソフトウェアの実行は次の2つのステップから成り立っている。その実行のルートオブジェクトと呼ばれる特定のオブジェクトを作成する。生成プロシージャと呼ばれる特定のプロシージャをそのオブジェクトに適用する。
19. 定義：オブジェクト：オブジェクトは何らかのクラスの実行時のインスタンスである。
20. ここまでの議論でソフトウェアが対応し、**表現しようとしているのは単に「モデル化されたシステム」である。**実はこのような捉え方はあまり一般的ではない。情報モデリングの説明では、多くの場合、「現実世界をモデリング」することを話題にし、オブジェクト指向に関する書籍においても似たような表現に束縛されている。
21. ソフトウェアシステムは現実のモデルではない。せいぜい何らかの現実の、ある部分のモデルのモデルである。病院の患者を監視するシステムは病院のモデルではないが、病院の管理の特定の側面がどのように扱われるべきかを示す誰かの味方を実装したものである。
22. これはADTモデラーのモットーと呼んでもいい-あなたが何であるかではなく、何を持っているかを教えてください。
23. 非常に厳密に管理されている状況を除いて、真面目なソフトウェア開発に手作業のメモリ管理は適さない。
24. 治療よりも予防が大切なのである。多くの研究が示しているのは、間違いを修正するコストはその発見が遅れれば遅れるほど天文学的に増大するということである。型エラーを早期に指摘してくれる動的型付けは、信頼性探求のための基本的な道具なのである。
    25.　結果的に、仕様書を書くことこそが、実際にソフトウェアが正しいことを保証する正しい第一歩であると言える。
25. 事前条件と事後条件は、それぞれrequireとensureというキーワードを使ってルーチン宣言の中に明確に示される。
26. もしそちらがpreを満たした状態でrを呼ぶと約束して下さるならば、お返しに、postを満たす状態を最終的に実現することをお約束します。
27. どんな事情があっても、ルーチンの事前条件に当たるテストを、ルーチン本体で行ってはならない。
28. シンプルさが重大な判断基準となる。複雑さは品質の敵である。この観点で見直すならば、冗長な検査はもはや無害とは言えないだろう！
29. エラーとは、ソフトウェアシステムの開発中になされた誤った決定である。欠陥とは、意図した振る舞いからシステムがそれてしまう原因となるソフトウェアシステムの特性である。フォルトとは、何らかの実行中に意図した振る舞いから外れてしまうソフトウェアシステムのイベントである。
30. ルーチン作者は顧客より賢くあろうとしてはいけない。すなわち、ルーチンが何をするか分からないような、特定の異常な状況がある場合、事前条件を通して明示的にそれを除く。この態度こそ、概ね、この本全体を通しての主題に対する結論である。すなわち、自身の仕事に専念するモジュールの集合としてソフトウェアシステムを構築する。
31. ルーチンが契約を満たす状態で実行を終えた場合、そのルーチンコールは成功である。成功しなければ失敗である。
32. ルーチンの実行中に例外が起き、ルーチンがその例外から回復しない場合に限り、そのルーチンコールは失敗となる。
33. ルーチンの実行中に起こった例外を処理するには、正しいやり方が2つある。リトライ：例外となる状態を変更し、ルーチンを最初から実行し直そうとする。失敗：環境を綺麗し、実行を終了し呼び出し側に失敗を報告する。
34. 好き勝手に再定義をしてはいけないということだけは、しっかりと覚えておいてほしい。許されるのは意味を変えない再定義だけである。
35. 継承はその時々で、拡張性と見做される場合もあるし、特殊化とみなされる場合もある、実はどちらも正しい。それは単なる見方による違いに過ぎない。