オブジェクト指向でなぜつくるのか後半まとめ
オブジェクト指向でなぜつくるのか。後半まとめと感想
デザインパターン
オブジェクト指向を利用すると独立性が高まり、ソフトウェア部品を再利用することができる。ことがメリットであったが、デザインパターンのように、ソフトウェアそのものではなく、ソフトウェアを作る際に用いられたアイデアを再利用することもある。
代表的なのがGoFによるデザインパターン。ソフトウェアを開発するときは通常、一から組み上げず、先人たちが数々の難所を乗り越え、試行錯誤によって築き上げた設計知識の集積を用いて開発を行われる。
オブジェクト指向が登場した後の各言語の標準ライブラリにはデザインパターンの考え方を用いて提供されているものもある。
OOPとUML
OOPは現実世界を全てソフトウェアに置き換えるような考え方はできない。ソフトウェアは現実世界の仕事の一部をシステム化して肩代わりしているものに過ぎない。
OOPは二つの側面があり、これらは分けて考える必要がある。１つはプログラミング的な側面（クラスでサブルーチンやインスタンス変数をまとめるとか、カプセル化やポリモーフィズム、継承など）、もう１つは汎用的な整理術という側面。
この二つの側面は前者を下流工程、後者を上流工程に分類することができる。
OOPの概念にクラスとインスタンスの関係があるが、これを集合と要素の考え方として捉えることができ、スーパークラスとサブクラス（継承関係）は全体集合と部分集合という考え方に分けることができる。
こうした集合論的な考え方は上流工程において、現実世界の役割を整理したり、説明したりするのに用いられている。
例えば上流工程で用いられるUML（処理の流れやデータ構造を図示できるモデリング言語）の中にクラス図があるが、これを用いると現実世界の物事を集合の考え方で分類できる。
具体的には電化製品が全体集合、冷蔵庫が部分集合のような考え方ができる。
またUMLを使うと現実世界のそれぞれの役割をその関係性とやりとりから図示することができる。そうしたことができるツールはいくつかあるが、例えばコミュニケーション図を用いると、個々のオブジェクトを線で結び、メッセージパッシング（メソッド呼び出し）をオブジェクト同士の関係に着目しながら図示することができる。
UMLではそうした現実世界の説明に役立てることもできるが、ビジネスアプリケーションにおいては先ほど挙げたクラス図を用いると、現実世界に存在するものを構造化されたソフトウェアデータとしてそのまま映し取ることができる。これを概念データモデルという。
概念データモデルはソフトウェアのデータモデルであることから、これがデータベースの構造にそのまま反映される。
感想
オブジェクト指向はプログラミングをしていると自然と触れているものではあるが、その成り立ちは、OOP登場以前の技術的な課題を解決するものであり、大変興味深かった。学習してみると下流工程から上流工程まで幅広くカバーできる概念でもあり、オブジェクト指向の考え方が取り入れられた個別の技術をもっと学ぶ必要があると感じた。またデザインパターンの書籍なども読んで理解を深めていきたいと思う。
書籍的にも体系的にまとまっていて、初心者から中級者までおすすめできる良い書籍だった。
