読書メモ：オブジェクト指向でなぜつくるのか

オブジェクト指向でなぜつくるのか 第2版の読書メモです。

※ オブジェクト指向プログラミング（OOP）

1. オブジェクト指向はソフトウエア開発を楽にする技術

オブジェクト指向が混乱や誤解を招く理由が書かれていた。私がオブジェクト指向について初めて勉強したときは、説明の中に犬とか猫が出てきた気がする。その比喩では混乱したというより具体的にどう実務のコードに落とし込めるのかがさっぱり分からなかった記憶がある。だから具体的なコードが盛り込まれてる、これらの本

• オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
• オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座
• 増補改訂版Java言語で学ぶデザインパターン入門

を読んで初めて実務に落とし込む感覚が見えてきたんだよな。でも他人にオブジェクト指向を説明するときは、やっぱり比喩で話してしまうと思う。例えば「大学」クラスにインスタンスが具体的な大学名で、「大学」クラスのスーパークラスが学校で、みたいな話をしたことがある。。

2. オブジェクト指向と現実世界は似て非なるもの

オブジェクト指向が現実世界とどう違うのかが書かれていた。「クラスの位置付けが違う、現実世界の人は自分で判断して行動する。」その通りすぎるんだけど、そこを深く突っ込んで違いを考えたことがなかったから明文されていて気持ちよかった。あとポリモーフィズムの説明「相手が具体的にどのクラスのインスタンスであるのかを意識せずにメッセージを送れる仕組み」、継承の「似たもの同士のクラスの共通点と相違点を整理する仕組み」という表現が明瞭で素敵だった。

3. OOP を理解する近道はプログラミング言語の歴史にあり

機械語でプログラムを書いていた時代からのプログラミング言語の歴史が書かれていた。ITは基本的に過去の改良を繰り返してる世界だから、対象がなんのために出来たのか？という話は、対象の理解を助けてくれるから好き。同じプログラムが機械語、アセンブリ、FORTRAN で書かれてるところが面白かった。16進数で書かれても全然分からん。当時は if や for もローカル変数もなかったのかぁ。クラスもないから結局はグローバル変数を使わなきゃいけないんだって。大変。。

コラム：プログラミング昔話

ちょうどデザインパターンのインタプリタパターンを勉強していて、普段使ってる Ruby は C 言語のインタプリタで解析して機械語にされるってことか！じゃぁ C 言語はどうやって…？と考えていたときのコラムだったので、まさか最初は機械語でコンパイラを作っていたことにビックリした。

4. OOP は無駄を省いて整理整頓するプログラミング技術

オブジェクト指向の基本的な仕組みの説明でした。インスタンス変数は仲間内（クラス内）だけのグローバル変数、ポリーモーフィズムはサブルーチンを呼び出す側のロジックを共通化する仕組みという説明は新しい視点だった。また、人間が良いプログラムが書けるよう、間違いにくいよう機能が取捨選択され、新しい言語が作られていることが分かった。あと、C 言語と C++ の違いが曖昧だったけど、そもそも C 言語は言語として OOP の仕組みを実装していないことを知った。だから無駄が生まれないし、組み込み系で使われるのか。

プログラミング言語の進化

5. メモリの仕組みの理解はプログラマのたしなみ

オブジェクト指向で書いたコードがメモリにどのように展開されているのかが書かれていた。これまでの私は「メモリリークを避けるため、大きいデータを読み込むとき（メモリ展開するとき）は一行または数行ごとにする」は意識していたけど、メモリ内部の領域のことやクラスやインスタンスが、どのメモリ領域に展開されているのか？など考えたことがなかった。ポリモーフィズム、継承ではメソッドテーブルが共通化を支援している。これはオブジェクト指向言語自体がどうやって実装されているのか？に繋がるね。メソッドテーブルは仮想関数テーブル（VTable）とも呼ばれるよう。そしてそれを C 言語では自前で実装するらしい。（参考：C言語とオブジェクト指向）この仕組みが分かったら実装できそうな気がしちゃう。

オブジェクト指向プログラミングのメモリの仕組み

6. OOP がもたらしたソフトウエアとアイディアの再利用

フレームワークやデザインパターンについて書かれていた。ちょうど Java のデザインパターンを読み終えたばかりだったので

このようにデザインパターンが使われていることがわかると、そこから開発者の意図を汲み取ることができます。そしてそれにより、適切な利用方法の理解にもつながりま す。

に大いに納得。ハリウッドのくだりで書かれていたフレームワークとライブラリの違い、自分の認識と合っていて良かった。コンポーネントという用語はクリーンアーキテクチャ本でも使われていて、具体的なイメージが未だに曖昧。本の中でも漠然としていた。

7. 汎用の整理術に化けたオブジェクト指向

オブジェクト指向が下流工程の「プログラミング技術」と上流工程の「汎用の整理術」という2つの顔を持つことを押さえておいてください。

はい。認識曖昧でした。
現実世界をプログラミングに…じゃなくて、プログラミング技術が先にあって、それが後に整理術に変化した。その考え方ならプログラミング技術の枠は超えないよね

コラム：オブジェクトの向こう側

プログラミング技術のためにコンセプトを作ったわけじゃないんだね。当時、アラン・ケイ氏はこのコンセプトが現実世界のモデル化に使われると思ってたのかな。

8. UML は形のないソフトウエアを見る道具

目的に合わせた UML の使い方が書かれていた。クラス図やシーケンス図、ユースケース図も全部 UML だってこと知らなかった。未だに UML 自体がバージョンアップされてるんだね。

UML バージョン2で定義されている13種類のダイアグラム

図がプログラムを表現するために使われているのか？整理するために使われているのか？意識したことなかった。私は上流工程に関わることが少ないので、 UML を見る機会としては技術系の書籍（デザインパターンとか）が多いから、プログラミングを表現するために使われているイメージが強い。

シーケンス図でプログラムを動きを表現するとき、メソッドの矢印と実際のコードを結び付けるのによく混乱していた。。でも、整理術で仕事の流れを表現する場合は理解しやすいと思った。あと UML を言語やプログラムでは理解し辛いものを図で分かりやすく表現するための補助ツールとして割り切ってるところが良い。

9. 現実世界とソフトウエアのギャップを埋めるモデリング

ソフトウエアに落とし込むためのモデリングが3ステップで書かれていた。段階的にステップを踏むことで現場の様子からコンピューターに肩代わりさせる部分を分けることができる。これまで自分でモデリングをしたのはツールや規模の小さいサービスが多かったから、正確に3ステップを踏んだことがなくて、"こんな感じ"の感覚で押し切ってた節あるなぁ。業務分析をキチンとやってみたいな。

「業務分析と要求定義をおろそかにすれば、最終的に利用者にとって役立つシステムは決して作れないでしょう。」は心にグサッときた。以前に作ってた個人開発アプリの業務分析と要求定義を試してみたくなったし、モデリングの参考書籍で紹介されていた本も読もうと思った。

10. 擬人化して役割分担さえるオブジェクト指向設計

良い設計のためのポイントが書かれていた。特に意識せずとも依存関係を循環させたことないんだけど、そもそもオブジェクト指向プログラミングが出来てなかったんだろうなぁと思った。増補改訂版Java言語で学ぶデザインパターン入門の Memento パターンで紹介されていた「カメラで写真を撮ってフィルムに記憶する」という例えは、まさに擬人化。

11. オブジェクト指向から生まれたアジャイル開発と TDD

ウォーターフォール型開発プロセスの問題点である、動かして初めて分かる課題へどう対応するかの解決策として反復型の開発プロセスがあり、アジャイル開発はその総称として使われている。これまでアジャイル開発という言葉が私の頭の中で一人歩きしていて定義が曖昧だったけど、反復型であることが分かりスッキリした。そしてアジャイル開発のプラクティスとして TDD やリファクタリングがあるのも納得できる。小さなイテレーション単位で開発を行う考え方はフィードバックが早く貰えるということで、TDD はアジャイル開発の考え方をプログラミング作業に取り入れている。

12. オブジェクト指向を使いこなそう

これまでのまとめが書かれていた。サービス指向とマイクロサービスの違いが気になったので調べた。

参考）SOAと何が違うのか、マイクロサービスの要点を4項目に整理 | 日経クロステック（xTECH）

SOA（サービス指向アーキテクチャー）は主に業務プロセスとソフトウエアサービスの分離や、既存のソフトウエア資産の再利用を主目的としている。概念は比較的難解で、実現するためには複雑な技術の理解、ミドルウエア製品の導入などが必要だ。また、SOAでは「分割されたシステム（サブシステム）間の連携をつかさどる部品」が必要となる。この部品はオーケストレーションと呼ばれ、SOAを導入したシステムはオーケストレーションを軸にした一極集中の構成をとる。そのため、オーケストレーションが性能やシステム改修頻度など、さまざまな局面でボトルネックとなることが課題である。

一方、マイクロサービスアーキテクチャー（MSA）ではソフトウエアに対して段階的な機能追加を可能にすること、管理をより簡単にすることなどが主な目的だ。SOAと比較して概念はシンプルで、導入にあたって押さえるべき要素技術も複雑ではない。システム間の連携をつかさどるオーケストレーションのような仕組みも必須ではないため、ボトルネック問題も生じにくい。

13. 関数型言語でなぜつくるのか

純粋関数型言語の特徴を従来のプログラミング言語との比較を交えつつ書かれていた。 関数型言語についての私の知識

• Ruby に関数型言語の影響を受けている（？）map や reduce などのメソッドがある
• Ruby 2.7 で追加されたパターンマッチ機能は関数型言語で使われている機能である
• ハッキリ理解してるわけじゃないけど 副作用がない という言葉を聞き齧ってる

レベルです。でも本章の導入クイズで関数型言語へグッと引き込まれた。

想像以上に純粋関数型言語の仕様は制約が多く、従来のプログラミング言語とサポートしている機能が全然違っていることに驚いた。この制約のながでプログラム書いてみたい〜という欲が出てテンションあがった。次に「[増補改訂]関数プログラミング実践入門 ──簡潔で、正しいコードを書くために」を読む予定だったので、このタイミングでこの関数型言語の大枠の考え方、特徴を理解できてよかった。

感想

言葉が明瞭。重要な単語をぼぼ一言表現している箇所が分かりやすかった。また、混乱するであろう部分は丁寧に切り分けながら順序立てて解説してくれるところが良い。既に自分が理解してる箇所では再確認と新しい視点をもらったし、自分の足りない部分（モデリングや関数型言語）では深堀を参考書籍で勉強しようと思えた。