はじめに
改めて「ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用」(以下「ちょうぜつ本)を読んでみました。
自分はこの本、電子版が出た2022/12/07に出たときにすぐ買って読み切りました。 ただこのときには消化不良なところがあったので、感想は書けずにいました。 とは言え良書なのは間違いないので、会社で勧めてました。
1回目はざっと読んだのもあり消化不良だったのですが、2回目はじっくり読んでみました。
「オブジェクト指向」と私
小学生の作文みたいな見出しですが、自分と「オブジェクト指向」の出会いについて書いてみます。
自分が「オブジェクト指向」というのを初めて知ったのは大学生の頃、大学で出会ったNeXTコンピュータとNEXTSTEPというOSです。このブログのURLに nextstep が入っているのはこのNEXTSTEPが由来です。
このNEXTSTEPですが、「オブジェクト指向」を全面的に採用されたことでも知られています。Objective-CというC言語に「オブジェクト指向」の元祖と呼ばれるSmalltalkの機能を取り入れた言語を採用しています。NEXTSTEPは商業的には成功しなかったものの、ジョブズによる乗っ取りAppleによって買収されて、Mac OS X(現在のmacOS)やその派生OSであるiOSなどに受け継がれています。
自分がプログラミングを始めて3つ目に使った言語がそのObjective-Cでした。1つ目がBASIC(正確には「N-88日本語BASIC(86)」)、2つ目がC言語、3つ目がObjective-Cです。しかもNEXTSTEPはその洗練されたAPIと開発環境で知られています。すなわち最初に「オブジェクト指向」に触れるにはとても良い環境でした。
NEXTSTEPとObjective-Cに触れたのが1995年、今から28年前のことです。 それからRuby、Java、Pythonと「オブジェクト指向」と呼ばれる言語を色々触ってきて、もうシニアやベテランと呼ばれる年齢になってきたのですが、いまだに「オブジェクト指向」って何？と呼ばれると答えられないんですね。 だからこの文章はずっとカッコ書きで「オブジェクト指向」としていました。
ただ自分の中では「こういう使い方は良い」「こういう使い方はダメ」みたいな基準はなんとなく頭の中にあります。
よくある誤解にハマらないように丁寧に説明している
ちょうぜつ本では「オブジェクト指向を定義することはできない」と書いています。 そして、この本のタイトルは「定義」ではなく「活用」です。 その「オブジェクト指向」とそれを取り巻くものについてどのように使えばいいか丁寧に解説しています。
とは言え、全く勝手な話をし始めるのではなく、オブジェクト指向の特徴としてよく言われる 「カプセル化」「継承」「ポリモーフィズム」をきちんと取り上げて誤解のないように説明しています。
例えば誤解の多い「継承」ですが、この本では「継承／汎化」としています。 「差分プログラミング」で終わってはいけないし、「継承アレルギー」になってしまってもダメで、 抽象を扱うことを重視した記述になっています。
この本はこのように、「よくある誤解」にハマらないように説明しつつ、 「よくある誤解の反動」に陥らないようにするために丁寧に書かれています。 1回目読んだときは消化不良だったのですが、2回読んでなるほどと自分の中で消化できました。
「反動」から脱出できたPythonでの経験
再び自分の話をします。
この記事を書いてて思い出したのですが、自分は数年前まで「反動」にハマってたなと思い出しました。
先に書いた「継承アレルギー」はかつての自分がそうでした。前の会社ではJavaを使っていたのですが、 継承が多用されたコードに嫌になって、もう継承がない言語が使いたいと思っていました。Goのように。
ですが転職して、いきなりPythonをやることになりました。 どの言語でもやるつもりはいましたが、Pythonは正直言語としては不恰好でした。 interfaceはないし、C++で忌み嫌ってた多重継承はあるし、到底好きになれませんでした。
とは言えPythonを使うことになった以上、Pythonのやり方に慣れる必要があります。 多重継承も使わないわけにはいかないので、ちゃんと理解しました。 そうして2年も使うとだんだん慣れてきて、今では社内では「Pythonなら任せろー(バリバリ)」という感じです。
まあ正直今でもPythonの言語仕様は好きとは言えないし、最近はTypeScriptを書くことの方が増えたし、Goはやってみたいんですが、 それでもPythonをそれなりにやりこんだ経験は自分の糧になったなと思います。
この他にもやってみないと分からない、避けていたが読んでみて始めてわかったことがあります。 例えば書籍「Clean Architecture」はその1つです。 巷ではよく「“Clean Architectureの4つの円を実装してみた” みたいな記事」が出ます。 それはそれで悪いとは言えないんですが、正直あの通りやるのが正解とも思えないなぁと思って距離を置いてきました。
ですがとあるきっかけで読んでみたところ印象は変わりました。 表紙に「アーキテクチャのルールはどれも同じである!」と書いているように、 普遍的なアーキテクチャのルールについて丁寧に書かれた本だと感じました。
クリーンアーキテクチャがスタート
再びちょうぜつ本の話に戻ります。 この本が発売されると知ったときまずびっくりしたのがその目次でした。
- 第1章 ›› クリーンアーキテクチャ
- 第2章 ›› パッケージ原則
- 第3章 ›› オブジェクト指向
- 第4章 ›› UML（統一モデリング言語）
- 第5章 ›› オブジェクト指向原則 SOLID
- 第6章 ›› テスト駆動開発
- 第7章 ›› 依存性注入
- 第8章 ›› デザインパターン
- 第9章 ›› アジャイル開発
特徴的なのは第1章の「クリーンアーキテクチャ」です。 最初に「クリーンアーキテクチャ」を説明するとは思いもよりませんでした。 しかし読んでみるとなるほどという感じでした。
まずこの本はオブジェクト指向の「定義」ではなく「活用」のための本です。 そして、その「活用」のためには「動機」が重要です。 その「動機」は色々考えられますが、この本では「より良い設計をしたい」という動機を起点にしています。 本のタイトルも「設計入門」が入ってますし。
先ほど「“Clean Architectureの4つの円を実装してみた” みたいな記事」と書きましたが、 このような記事が多く出ているのは、裏を返すと「より良い設計をしたい」という表れではないでしょうか。 そして「クリーンアーキテクチャ」の説明が最初に来るのはある意味当然かも、自分はそう感じました。
ウォーターフォールの幻影
ちょうぜつ本の最後は「アジャイル開発」です。 ここまでは技術的な「活用」でしたが、最後は仕事における「活用」の話です。
自分はこの章についてはごく当たり前のことだと思っています(それこそが重要なんですが)。 アジャイル開発の具体的な中身についてちゃんと理解したのは今の会社に入ってからですが、 この章に書かれていることは倫理の話なので、理解できるのが当たり前だと思っています。
むしろこの本や次の記事に書かれているように、 「ウォーターフォール」というのが幻影であることが知られてもそれにすがるのが自分には謎です。 考えられるとしたら、「最初に計画する＝ウォーターフォール」と勘違いしているんじゃないかなと。
なお、この本が出た後Iterative and Incremental Development: A Brief Historyという記事を見つけたのですが、IID(Iterative and Incremental Development)と呼ばれる反復的かつ漸進的な開発は1950年代にまで遡れます。
Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s.
(日本語訳)多くの人は反復的かつ漸進的な開発を現代の実践だと考えていますが、その応用は 1950 年代半ばまで遡ります。
これが現代のアジャイル開発と一致するとは言えなくても、少なくとも「ウォーターフォール」よりは近く、かつ歴史は長いでしょう。
どうやって現実と折り合いをつけていくか
この本の最後はcolumn「ソフトウェア業界、その歴史」です。 その中で、2003年にRuby on Railsが出たことで「オブジェクト指向で設計する文化はリセットされました」と書かれています。
とは言え現実として仕事ではRailsのようなフルスタックフレームワークが使われることが多いです。 仕事の性質上、自分たちがゼロから技術選定することは少なく、 すでにあるチームに入っていくことがほとんどのため、この現実は(直接は)変えられません。
そこをどうやって折り合いをつけていくのか、最初はフルスタックで作ったとしてもどうやって移行していくのか、 そもそも最初から使わないという選択肢をどう持たせるのか、そのためにはどういう教育が必要か、 そういったことが今の課題です。特に最後ですね。
個人的にはDjangoは「アプリケーション」という単位があること、 テンプレートでできることが(あえて)限られていること、Pythonはパッケージ間の相互依存はエラーになるなどの理由から、 RailsやLaravelと比べるとまだ管理しやすい方かなと思っていますが、 CRUDには限界を感じてて、CQRSにしてCommandの中でEntityの一意性をとる感じかなとは思っています。 Hibernateは(本当はよくないんですが)個人的にアレルギーがあるので、 Doctrineとか他のORMは機会があれば使ってみたいなと感じています。
おわりに
めもりーちゃんのジト目とそけっとちゃんのツインテが好きです。
2023年の振り返り→