データ思考プログラミングの紹介
このポッドキャストは、ギークの2人が興味がある技術や熱中していることについて語り合う番組です。
オクです。
ゾイです。
最近ですね、データ思考プログラミングという本を読みまして、今回はその本の話をしていきたいなと思います。
はい。
この本ですね、海外の書籍の翻訳本であるようなんですけども、
海外のプログラミングの書籍、特にプログラミングのパラダイム的な本みたいなものを読んでいくと、
冒頭の著者、前書きみたいなところで、エキサイティングな体験みたいな、
そういうあまり日本では使わないような表現で、そのプログラミングパラダイムの面白さみたいなことを紹介している文章を結構見ると思うんですけど、
今回この本を読んだ自分の経験、体験っていうのが、まさしくそういうエキサイティングな体験っていうものにちょっと当てはまるような内容だったなと感じています。
冒頭に言ったこのデータ思考プログラミングっていうこのタイトルというか、いわゆるこのプログラミングのパラダイムなんですけど、なんか聞いてみてピンとくるようなところはありますか。
そうですね。あんまり普段は聞かないかなっていう感じはします。よく聞くのはオブジェクト思考みたいなのをよく聞くなと思います。
そうですね。私もそちらの方の方がよほど聞くなというような感じだと思いますね。
自分もなんていうか、この本をタイトルとテーマでピンときて買いましたとかそういうことじゃなくて、ちょうど当時、これ買ってからちょっとしばらく経ってから読んでるんですけど、
当時いわゆる決済みたいなことを考えるときに、結局どういうデータ溜め込むとか、どういうデータのモデリングするかみたいなことを考えてた時期があって、
そういった中でデータがポイントなんだよな、みたいな意識を持って、タイトルがそれっぽいから買った、みたいなところの中の一冊って感じですね。
オブジェクト思考と設計の複雑さ
具体的にどういうことを考えている本なのかってことを話していきたいんですけども、
本書だとオブジェクト思考を前提に設計を複雑にした例、設計が複雑になっていってしまうような例っていうのが出てきます。
図書館のソフト、図書館を管理するようなソフトを作るときの例があがってるんですけども、
スライドの1枚目のほうだと、今画像でも載っけてるかと思いますが、スライドの1枚目のほうだと、
いわゆる図書館を管理するライブラリアンってクラスがあって、利用者のメンバーがあって、
両者ともにログインできるようなものがあるので、それをユーザーとして継承して持たせる、みたいなモデリングをさせているというものです。
これがLIPユーザーっていう、一部特別扱いするユーザーみたいなものの権限を追加しましょうってなった際に、
メンバーだったりとか、一部権限を持ってるものをクラスでやったときに、複数継承を考えなきゃいけなければ、
考えなければいけないみたいな状況が発生して複雑になってしまったっていう話が出てきています。
図は割愛するんですが、この後に特別管理みたいな権限が増えて、ますます複雑になってしまうんだ、みたいな例が実際この本書だと出てくるんですよね。
ここまで極端な例ではないものの、いわゆる継承で考えていくと、難しいよね、破綻するよね、みたいな例はよく目にもすると思いますし、
それゆえにいわゆるコンポジションとかメキシンでそういうものは進めましょう、みたいな例っていうのも結構あるかなと思います。
こういった状況に対して、この本だと割り切ってオブジェクトではなくて、いわゆるただのデータであるんですよと、
データなのだよというふうにして考えていってるってことが、ある種新しくて、ある種原点に帰ってる考え方のような気が私はしたんですよね。
なんでこういう原点に帰った感覚を覚えたのか、感覚を持てたのかっていうところを振り返って考えてみると、
自分、普段今お仕事的には設計をするときに、いわゆるオブジェクトの設計をするよりは、
結局データ、いわゆるほとんどRDBのレコードでどういうものを作っていくのかを考えるっていうことが基盤になってて、
ある種オブジェクト思考で考えてないみたいなところが実態としてあるからだと思うんですよね。
データとオブジェクトの関係
はい。
実は少なくともRDBを扱う開発してる人たちで、実は通定してるのは結局データで考えるデータ思考で、
その上からフレームワークがオブジェクト思考ベースなのでとか、クラスベースなのでみたいなことを理由にしたオブジェクト思考を上から被せる形で考えてる。
そういうことをある種矯正されているのに暗示があるのかな、みたいなことを思ったところがあるんですよね。
はい。
普段アクティブレコードと仲良くするみたいなのは仕事なので、比較的生のSQLに近いところでお仕事してると、
いわゆる出てくるデータっていうのは別に特定のクラスとか特定のオブジェクトじゃなくて、
ただに素直にレコード、素直にデータっていう形で出てくるところでやってる場合は、なんかちょっと違う感覚を持つ方がいるのかなと思ったりしました。
ざっとこの本の内容みたいなのをご紹介してみたんですけど、どうですかね。
実はオブジェクトじゃなくて、結局普段データで考えてるような感覚ってありますか。
そうですね。
あんまりその2つは、個人的には引き続きではないように扱っているとは思いますね。
データがどうあるべきかと、オブジェクトがどう振る舞うべきかは、あんまり互いに干渉しないような気はしてます。
ただ、気をつけないといけないのは、オブジェクトの振る舞い、こうあってほしいっていう振る舞いをデータにすべきかどうかっていうのは考えなきゃいけないっていうのは思います。
うまい例が出てこないです。
よく悩むのは、例えば1000円の商品を100円値引きして900円で売ってますみたいなのを、
1000円と100円と900円っていうのを、どれをデータに、データベースに入れるべきで、
どれを、どこまでオブジェクトの動きっていう風にするかっていうのは、悩むかなぁとは思います。
この3つってどれか2つあれば、3つ目が導けるので、
最悪、元値1000円っていう元値と値引き額は100円だよっていうことだけ覚えておけば、
データに入っていれば、いくらかっていうのは、計算すればオブジェクトの振る舞いとして計算するだけで900円って求められるんですけど、
でもデータ帳を900円で出して、入れといた方がいいのかな、みたいなのは悩みます。
そうですね。今の話聞いてて、例えば値引きになってる理由みたいな、値引きのデータが関連するんだったら、
その値引き率のデータだけあれば別に、実際値引きされた額はいらないのか、みたいなところまで考えちゃうと、
実際どこまでデータで持つかっていう話と、どこまでオブジェクトで計算で出すのかはちょっと悩ましいですね、確かに。
それは確かにそうですね。
今回の例で言うと、そういったものを適用するときに、例えば特定の、何だろうな、
今回だと例えば、雑貨用品はこの計算方式で、日用品はこれで、みたいな場合分けをしたときに、
横展開していくと大変になるような例。要はユーザーと特定の管理者みたいなものがいたときに権限が複雑だよね、みたいな例。
っていうのは、単純にただのデータを渡したら結果が出るっていうふうに落とし込むと楽だよねっていう解釈なので、
結局それってクラスベース、いわゆるオブジェクトベースで、そういう特定の計算だけ出す処理はミキシングで外から与えていって、
継承関係で持たなければある程度解決するよなっていうのも全く同意なんですよね。
レイルズ的に言うとコンサーンですか?とかでやっても別に構わんよねって感じはするのは全く同意ですね。
ただ今回で言うと、あえてこれを極端な例と言えば極端な例なので、ここまで振り切って理論整然と書いてある本だと、
冒頭に言ったエキサイティングな体験、エキサイティングな読書体験っていう感じがあったとは思いますね。
結構お勧めだと思います、私。今回はデータ思考プログラミングという本の話をしてきました。
概要欄のほうにもリンク貼っておきたいと思いますので、ちょっと興味あるなと思った方はぜひお手に取ってみてください。
