本書について
ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用
技術書「ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用」レビューとまとめ。Bobおじさん本を読む前の準備として最適な一冊。からリンク。
第３章 オブジェクト指向
3-1 オブジェクト指向の定義はない
3-2 カプセル化
3-3 多態性
3-4 継承／汎化
3-5 構造化プログラミングと何が違うのか
最近、Twitterなどでもよく議論されている、オブジェクト指向とは何か、オブジェクト指向は終わったのかといったことに切り込んだ章。オブジェクト指向は、古い本で解説されていることが、現代では異なる解釈になっていたりして、混乱を招いている。私も厳密にこういうものだということは理解できていたわけではなかったが、以下の文言が、著者の方の様々な積み上げや経験から裏打ちされた結論なのだということで、なるほどと思った。
筆者の主張は、オブジェクト指向を定義することはできないということです。
歴史的に、オブジェクト指向というのは、明確な定義から発展したものではないのです。なので、何であるかを主張することにはあまり意味がありません。けれど、陥りやすい誤った理解だけは避けるべきです。
最近、トレンド的に「オブジェクト指向は終わった」といった論調のブログ(Qiita, Zenn含む）やツイートを多く見る。
その発端は、おそらく、プロになるJavaの著者であるきしださんのツイートやブログなのかと思っている。
きっかけは高齢化問題と、Software Designにオブジェクト指向記事を書いてほしいといわれたときに考えてみるとオブジェクト指向むしろ有害だなってなったやつですね。オブジェクト指向を学びなおそうという特集の一部なのに、「オブジェクト指向いらんわ」って書こうとしたｗhttps://t.co/0YcyqC5P52
— きしだൠ(K1S) (@kis) January 12, 2023
発端はこのあたりにうかがえます。2005年7月https://t.co/G9CbHFqQxv
— きしだൠ(K1S) (@kis) January 13, 2023
雑にいうと、ソフトウェアエンジニアはもうオブジェクト指向なんか気にしなくなってるんだけど、エンジニアを中心としたソフトウェア開発エコシステムのうち、エンジニア周辺にいる例えば教育や出版といったところには根強く残ってるので、そこをどうにかしないとねというところ
— きしだൠ(K1S) (@kis) December 10, 2022
表面的に理解すると、オブジェクト指向はもう古いからやらなくていいと勘違いしてしまいそうだが、言いたいのはおそらくそう言うことではなく、何でもかんでもオブジェクト指向と呼ぶのではなく、ソフトウェア工学として今まで蓄積されてきたものがあるわけで、全ての原則や設計技法がオブジェクト指向というわけではないですよといったことなのかなと思っている。
結構極論を仰られているきしださんが、最近、オブジェクト指向神話からの脱却を書いていたので、興味はある。この本を読んだ、このちょうぜつ本の著者の方が、以下ツイートをしていた。
WEB+DB PRESS の「オブジェクト指向神話からの脱却」の感想です。→ 90 年代にもてはやされた考え方のうち、もう生き残ってないものがこんなにあるのに、その個々を知らずに当時の調子でオブジェクト指向すごいらしいと(データにメソッド生やすぐらいしかしてないのに)盲信するのはもうやめなさいだな
— 田中ひさてる 新刊発売中 (@tanakahisateru) December 27, 2022
ちなみに、このちょうぜつ本は、きしださんのレビューも受けており、内容を否定されなかったとのこと。この辺りは謝辞に書かれていた。実は、ここも結構重要なポイントで、それなりの影響力をもつきしださんが、積極的にオブジェクト指向やめろといったことを発信しているが、そうした背景があってこの本をレビューして内容を否定しなかったというのは、この本が現代的な観点でしっかりとまとめあげられているからなのだろうと考えている。
よく、オブジェクト指向はこの世の真実のようなものをそのまま写し取ったものと説明されていることがある。これは、オブジェクト指向でなぜつくるのか でもそうだったと思う。しかし、この本では、その点はしっかりと否定している。
情報のモデリングとは、現実そのものではなく、現実を恣意的に分析した部分的な断面なのです。カーディーラーにとっての自動車は商品の一種ですが、自動車製造工場にとっての自動車は部品の集合体です。意味のあるオブジェクト指向とは、両方の概念を併せ持つ統合モデルを考えることではなく、アプリケーションに合わせてどのモデルを切り捨てるかを判断することです。
この本のオブジェクト指向の説明は、今までのどの本よりも、納得感のあるものだった。
さらに、どういうものがオブジェクト指向ではないかの説明がある。
- クラス構文のある言語で書くことではない
オブジェクト指向の考え方自体は、クラスという言語機能に縛られるものではない。例えばJavascriptのclassはシンタックスシュガー。 - 状態管理は関係ない
状態を持たない関数型があるため、その対比として状態変化を管理するプログラミングをオブジェクト指向と誤解する人がいたが、状態変化は非関数型だが、すなわちオブジェクト指向というわけではない。 - 手続き型は関係ない
続いて、カプセル化、多態性、継承について説明がある。好感を持ったのが、継承をあえて、継承/汎化としている点。継承は、効率的な差分プログラミング（共通処理を基底クラスに抽出）のためのものではなく、あくまでインタフェースや抽象化のためのもの。基本は委譲すればよい。そうした誤用への警鐘として、汎化と書いているのは、誤解を招かない上でも良い見出しと思った。
ここでのカプセル化の説明は、他の本とは一線を画す。パッケージ原則とも絡めて解説されている。例えば、以下の文。
パッケージの原則には全再利用の原則（CRP)と閉鎖性共通の原則（CCP）がありました。パッケージには関係の弱いものを含みすぎず、かつ、関係のあるものを十分に含むべきで、それが適切にできている状態を凝集度が高いと呼びました。オブジェクトへのカプセル化は、これと同じことを、プログラミング言語による概念表現として実現します。
カプセル化して関心を分離し、委譲で呼び出す。そうすると、呼び出し側は委譲した側の内容を深く知る必要がなくなる。
カプセル化による関心の分離は、最小知識の原則（デメテルの法則）で知られている。この原則では、$this->car->getEngine()->start();等のように、getterで得たオブジェクトのメソッドを呼ぶコードを気軽に書かないようにするために、メソッドチェーンを禁止事項に挙げている。
同じ格言として、”Tell, Don’t Ask.”もある。つまり、これをやれ、と命令するだけで、何かを聞いた後に呼び出し側で判断して何かをするようなことは避けるべきということ。これだけだとメソッドチェーンの否定になるが、抽象度が同じレベルのオブジェクトを返すメソッドをメソッドチェーンで記載するのは問題がないことが説明されている。
多態性の説明もパッケージ原則と絡めて解説している。具体的なコードも多く、わかりやすい。もし、難しくてよくわからない場合は、Head First デザインパターン 第２版 やHead Firstオブジェクト指向分析設計 ―頭とからだで覚えるオブジェクト指向の基本あたりを読むのが良いと思う。ここでは、ロギングクラスを使って、Null Objectパターンの説明も書かれていた（具体的に、このパターン名が書かれていたわけではないが）。
どうやって抽象を抽出して、継承させるかは難しいが、分析のアプローチの仕方についても説明がある。もし、この説明だけで難しい場合は、やはり上記Head Firstオブジェクト指向分析設計を読んでからこの本にtryしてみるのが良いのではと思う。
そして、重要なことが書かれている。
この抽象による依存方向と開発順序のコントロールこそが、オブジェクト指向プログラミングをする最大のメリットです。
その解説のために具体的なコードがあるため、本を見た方が良いが、要するに抽象クラスとその具象クラスをわけることで、パッケージを分けて安定したパッケージを作ることができるということ。
最後に、構造化プログラミングとオブジェクト指向プログラミングの違いが書かれている。明確に、オブジェクト指向は、構造化プログラミングではないと断言している。歴史的な構造化プログラミングの説明から始まり、オブジェクト指向との対比に繋げる説明は圧巻。よくここまで歴史を含めて調べ上げたなと思う。重要な点は以下と思う。
オブジェクト指向プログラミングでは、その抽象を仮に正しいとすることで、上位構造が下位と独立して正しいと言い切ることができます。具象の方にいくらバグがあろうと、抽象オブジェクトの利用者は、下位に混入したバグと無関係でいられます。観念的な存在ではなく「実際に開発工程で機能する抽象が実在する」ことが、構造化プログラミングにはなかった、オブジェクト指向プログラミング特有のメリットです。
第４章 UML（統一モデリング言語）
4-1 UML概要
4-2 パッケージ、クラス、インターフェース
4-3 集約・コンポジション
4-4 インスタンス図とシーケンス図
4-5 シーケンス図
4-6 UMLはプログラミング言語ではない
UMLについて、駆け足で最低限の説明をしている。もし、UMLについて理解が不足している場合は、リファクタリング 既存のコードを安全に改善する（第2版）で有名なMartin FowlerによるUML モデリングのエッセンス 第3版がおすすめ。
脱線するが、Martin Fowlerは、エンタープライズアプリケーションアーキテクチャパターン、通称PoEAA本でも有名。著者の方が、実はこのPoEAAについて漫画で説明する記事を書いていたため引用しておく。正直、まだ私はこの本は読めていない。いずれ挑戦はしたいと思う。
紙の本が難しくて意味不明だったみなさんが 20 年の時を経て PoEAA を完全に理解できるという最高傑作になったと思っています https://t.co/EAqmlnG49s
— 田中ひさてる 新刊発売中 (@tanakahisateru) December 30, 2022
コメント