世界は手続き型である。時間は流れ、イベントはひとつひとつ起きる。
世界はオブジェクト指向でもある。「人が猫を踏んでしまったとき[というプログラムを明示することはない。猫と人間というオブジェクトがあり、その相互作用が自動的に決まる。世界はオブジェクトの一連の相互作用であるとみなせる。
OODの反対: 世界を事前定義された手続きの塊として見る。
OOD: 世界をオブジェクト間を通過する一連のメッセージとして見る。本質的にプログラムの技法というより、世界の見方である。
一連のメッセージは自らについての情報を交換する: OODは依存関係を扱うことについてだといえる。
物事は変化する。変化は予測できない。変化に対応できるようにしておく。あとに戻れないような決定的な決断をせず、常に移動できる空間を残しておく。
行数ではなく、将来かかるコストで測定するべきだが、難しい。
従来の方法とアジャイルでは、デザインの意味が異なる。前者は完全な文書化、後者はどう書くか。
デザインの妥協は現在は楽だが、将来のコストを大きくさせることになる。つまり、未来から時間を借りてきているといえる。=技術負債。
デザインの損益分岐点はプログラマーの技術に依存する…経験の浅いプログラマーは設計が報われるポイントに達することがない…。
OODはオブジェクトとオブジェクトの間を通過するメッセージで構成される。
手続き型言語のデータ型はデータが何であるかを示す。考えられるすべてのデータ型と操作が備わっている。しかし全く新しいデータ型を作ることはできない。データとふるまいには溝がある。
データは変数にパッケージ化されてふるまいに渡される。ふるまいは何でもさせられるが、追跡ができない。データは、ふるまいが毎朝送り出す子供のようなものだ。
オブジェクト指向言語は、データとふるまいを分けない。データ+ふるまい=オブジェクト。
オブジェクトは互いにメッセージを送り合うことで一方のふるまいを引き起こす。
rubyはstring型の代わりにstring objectを持つ。文字列を操作する操作は、言語の構文ではなく文字列オブジェクト自体に組み込まれている。独自のstringofデータを持つが、そのほかは同じ。データはカプセル化され、公開するか否かはオブジェクトがそれぞれ決める。
文字列オブジェクトは独自の操作を提供するため，rubyは文字列データ型について知る必要がない。1つのオブジェクトが別のオブジェクトにその方法を送信するだけでよい。
メソッドとは、ふるまいの定義である。属性は、変数の定義である。
クラスから生み出されるインスタンスは、ふるまいは共通だが持つデータはそれぞれ独立している。
Rubyは多くの事前定義されたクラスが付属している。これが手続き型言語でいうところの型。Stringクラスはstringの定義である。
オブジェクト指向言語はそれ自体がオブジェクトを使用して構築されている。ここがポイント。
たとえば文字列クラスはそれ自体がオブジェクトで、Class classのインスタンスである。
すべてのstringオブジェクトは、固有のデータをもったStringクラスのインスタンスであり、すべてのclassオブジェクトは，固有のデータを持ったClassクラスのインスタンスである。