『オブジェクト指向でなぜつくるのか 第二版』読了の感想

勉強,思想,書評,設計

『オブジェクト指向でなぜつくるのか』を再読した。

エンジニアになって2~3年目あたりに先輩にお勧めされた書籍。改めて良書だった。

読んだきっかけ

最近、アプリケーションアーキテクチャやDDD、モデリングを学んでいる。その中で「そういえばこういう内容が書いてあったな」とこの本を意識することが多くあった。昔一度読んだ本だが、その時はまだ経験も浅く、エンジニアであり続けるという自覚も不十分だったため、この本としっかり向き合うことができていなかった。読書をしながらついつい目の前の仕事のことを考えてしまい、気がつけば数ページ記憶にない状態で読み進めてしまっていたのを今でも思い出す。

現在であれば、増えた経験と時間的余裕によりしっかりと「自分ごと」としてオブジェクト指向に向き合えるのではないかと思い再読した。

オブジェクト指向でなぜつくるのか

この書籍は、オブジェクト指向を汎用の整理術」「プログラミング技術」という二つの括りで捉える立場をとっている。

前者の「汎用の整理術」では、主に上流工程で行われる業務分析/要件定義/設計におけるモノゴトの整理に便利な手法としてのオブジェクト指向を扱う。こちらはUML(統一モデリング言語)によって要件や「システムに置き換えること」を明らかにする工程が簡単になった、というような文脈。

後者の「プログラミング技術」では、一般的なオブジェクト指向における三大要素「カプセル化」「継承」「ポリモーフィズム」(書籍ではカプセル化を「クラス」に置き換えている)について説明し、それらを「難しいソフトウェア開発をより楽しくする技術」として紹介している。

故に、「より楽に、楽しくシステムを設計・開発するためにオブジェクト指向でつくる」というのが掲題の問いに対する答えであると理解した。

オブジェクト指向の歴史

オブジェクト指向はしばしばプログラミングにおける大きなパラダイムシフトとして捉えられる。しかしこの書籍ではむしろ、オブジェクト指向はそれまでの開発手法や思想(構造化プログラミング等)の延長線上のものであり、何か抜本的な転換をもたらす革命的なものというわけではないとしている。

機械語 -> アセンブリ -> 高級言語(FORTRAN,COBOL等)とプログラミングのための言語が発展した。しかし言語の発展以上にコンピュータの普及速度は速かった。ソフトウェアの需要は爆発的に高まり、ソフトウェア危機が宣言されるほど需要と供給のバランスが歪なものとなった。より効率的な開発が必要とされ、一旦の答えとして「構造化プログラミング」が提案された。「順次実行」「条件分岐」「繰り返し」という基本三構造理論が確立し、この思想に強く影響を受けたPascalCといった言語が生まれ流行した。これらによって保守性の問題はある程度解消されることとなる。その後時代が進む中で、「構造化プログラミング」だけでは解決されない問題が観測されるようになった。グローバル変数の濫用による影響範囲の拡大、サブルーチンの再利用だけでは対応し切れないほど大きなソフトウェア開発増加。そこで台頭してきたのが「オブジェクト指向」という思想である。Simura67(先発), Smalltalk(思想の利便性を実証), Java(流行元)といったいくつかの言語による浸透を経て、「オブジェクト指向言語」は注目を集めることとなる。このような流れから、オブジェクト指向は現代では広く受け入れられる思想となった。

要約するとオブジェクト指向が注目された歴史は以上のような流れだという。こうみると確かにパラダイムシフトという捉え方はそぐわない。それまで積み重ねてきた技術やノウハウ、観測された問題に対応するため新たな手段として生まれた、正統進化の系譜であるとするのも納得がいく。

OOPに付随して発展した技術

デザインパターン、ガベージコレクション、ライブラリ、コンポーネント等についても説明がある。これらはオブジェクト指向(及びそれを含む技術全般)と一緒に発展してきた技術として紹介されている。

以前MVCパターン(アーキテクチャと呼ばれることもある)について調べた時に、SmalltalkがMVCの発祥だという話をみたことがある。web開発界隈にて、少なくとも数年前まではMVCパターンが主流だったことは言うまでもない(実際にはviewとmodelのオブザーバ関係を除いたMVC2が主流だったと思うが)。この技術もまた、オブジェクト指向と一緒に発展してきたものの一つと言える。

私のように、現代においてオブジェクト指向プログラミングをしている人間は、おしなべてそれまでの歴史によりつくられた仕組みの恩恵にあずかっている。こんなにも楽に楽しくプログラミングをおこなう我々は、先人たちに感謝せねばならない。

現状ではまだ、例えばメモリの使用量を一切気にせずプログラミングを行える段階にまでは至っていない。しかし次世代のプログラミングではそういったことも一切気にせず「やりたいことだけを書く」という夢のような状況になるのかもしれない。通信量、メモリ使用量、バリデーション、セキュリティ、実行速度を一切気にせず書けるのであれば、それはなんと幸せなことだろうと思う。プログラミングが"誰にでもできる簡単な仕事"になってしまうので私自身は困るが、世界はそうなった方が幸せに満ち溢れている気がする。

応用技術

書籍内で何度も繰り返される主張として、「システムは現実世界をそのまま置き換えるものではない」というものがある。オブジェクト指向プログラミングを語る際にはよく「現実世界をそのままプログラム(オブジェクト)にする」というような例え話が使われるが、確かに私の経験では実際の業務でそれを100%実現できたことはない。人間が行っている一部の業務や仕組みを定型のプログラムに直し、「一部を置き換える」ものを作るというのがより真実に近い。

現実全てをプログラムにすることは難しい。一方で、現実とソフトウェアがあまりに乖離していては使い物にならない。そのため、その乖離を防ぐ分析/設計プロセスを行う必要がある。この辺りはDDDの思想とも重なる。そこでこの書籍では「汎用の整理術」というオブジェクト指向のもう一面を使おうとしている。UML、アジャイルなどの開発プロセス、DIPなどをうまく使えばある程度それを防げる、という主張だと私は捉えた。

設計周りの難しさ、初期に構想したモデルと実装が乖離していきがちであることを肌で感じている私に、このあたりの話は深く刺さった。クリーンアーキテクチャやDDDを今学ぼうとしている理由はまさにそこなのだから。

全体的な感想

今回は再読となるが、改めてよい本だな、と感じた。オブジェクト指向の歴史、上流と下流でみた二つの側面、付随して発展してきた技術を体系的に知られるのがとても良かった。内容的には特に凝集度や結合度、よい設計とは何か、という部分をもう少し突き詰めて知りたかったが、それはこの書籍の役目ではないと考えているので、不満はない。

内容と自身の経験を鑑みると、特に汎用の整理術としてのOOPを活用できていないな、と感じた。

要件定義~テストまで一通りを行ってきた経験はある。しかしほとんどが自社サービス&自社チーム内での開発であったことから、UMLを使った図面であったり、詳細仕様が山ほど書かれている重厚な設計書を書いたことはない。恥ずかしながらチケットやその他管理ツール等でmarkdownか何かで目的や仕様をババッと書いて開発メンバーに渡し、詳細は随時事業側の担当者に聞きにいったり、Excelで管理していた仕様書やプロダクトバックログ、やりとりのログを参照して都度都度確認していた。一度くらいUMLでアクティビティ図やユースケース図、シーケンス図を描く経験をした方が良さそうだと感じた。PlantUMLというツールでUMLをコード的に書けるそうなので、来月あたりにそれを触る目標を取り入れたい。

勉強,思想,書評,設計

Posted by shoopon