「データ指向プログラミング」を読んだので、その読書メモをまとめていきます。
感想
自分にとって本書で紹介されている「データ指向プログラミング」というアイデアは、関数型プログラミングやスキーマ駆動開発におけるプラクティスを取り入れ、オブジェクト指向プログラミングが潜在的に持っている複雑性に対処するための方法論のように読めました。
本書では JavaScript のような動的型付け言語を前提とした例が多いです。そのため、TypeScript が台頭している昨今や、はたまた静的型付け言語を利用しているケースを考えると、紹介されているアイデアを適用する場合には開発者の工夫が必要に感じました。そもそも適用するべきなのか、という議論の余地もありそうです。
しかしながら古典的なオブジェクト指向プログラミングというパラダイムが持っている問題点を構造的に見つめ直し、それらを解決するために「4つの原則」というアイデアに昇華させている点は非常に勉強になりました。
以降では、自身の備忘も兼ねて、本書で紹介されているアイデアを簡単にまとめておきます。
オブジェクト指向プログラミングの問題点は何だったのか
そもそも、オブジェクト指向プログラミング（Object-Oriented Programming, OOP）の問題点は何だったのでしょうか？
オブジェクト指向プログラミングの問題点は、アプリケーションの規模が大きくなっていくとすぐに複雑（=理解しにくいもの）になっていくことだと言えます（OOP に限った話では無いかもですが）。
本書では、その複雑さの原因として以下の点が挙げられています:
- コード（振る舞いを表現）とデータ（ファクトを表現）が混在している
- → 他クラスとの関係の数が増え、難解になる
- オブジェクトがミュータブル（可変）である
- → コードを読むときにデータが変更される可能性がないかどうか余分に考える必要がある
- データがメンバとしてオブジェクトに閉じ込められている
- → 動作を含むコードが含まれてしまうため、データのシリアライズが容易でなくなる
- コードがメソッドとしてクラスに閉じ込められている
- → クラスの階層が複雑になる（継承などを行っていると特に）
データ指向プログラミングでは、これらの問題を軽減することを目指します。
データ指向プログラミングとは
データ指向プログラミング（Data-Oriented Programming, DOP）とは、ソフトウェアシステムの設計と実装をシンプルにすることを目的として、オブジェクト指向プログラミングや関数型プログラミング、スキーマ駆動開発におけるプラクティスを統合したプログラミングパラダイムと言えそうです。
データ指向プログラミングでは「4つの原則」を掲げ、これらの原則に沿ったプログラミングを行うことで、開発者にとって「よりシンプルで」「理解しやすく」「開発しやすい」実装を目指します。
実際に4つの原則を見ていきます。
4つの原則
DOP が掲げる4つの原則は以下のとおりです:
- 原則1: コードをデータから切り離す
- 原則2: データを汎用的なデータ構造で表す
- 原則3: データはイミュータブルである
- 原則4: データスキーマをデータ表現から切り離す
順番に簡単に説明していきます。
原則1: コードをデータから切り離す
原則1は コード（＝振る舞い）とデータ（＝ファクト）を分離して扱うというものです。
コードとデータを切り離すことで、関数型プログラミングにおける純粋関数のように、コードを副作用を持たないステートレスな関数として扱うことができます。その結果、関数の再利用性が高まり、そして単体テストも容易になるというメリットがあります。
原則2: データを汎用的なデータ構造で表す
原則2は、クラスのインスタンスなどを利用するのではなく、汎用的なデータ構造（マップや配列）を用いて表現するというものです。
汎用的なデータ構造を利用することで、言語にネイティブに存在するメソッドを多分に利用できるというメリットがあります。例えば、JavaScript であれば、配列を .map や .reduce などのメソッドを使って操作することが可能です。
原則3: データはイミュータブルである
原則3は、データはイミュータブル（不変）なものとして扱うというものです。
イミュータブルを前提とすることで、データが変更されていないことを保証されコードの安全性が高まるというメリットがあります。
本書では Immutable.js のようなライブラリを利用してデータの不変性を実現しています。
原則4: データスキーマをデータ表現から切り離す
最後の原則4は、Json Schema を活用してデータの型を定義しつつ、実装上のデータ表現においては定義した型をそのまま厳密に適用するのではなくある種「緩いつながり」を持ったまま扱おう、とするものです。
Json Schema という、言語に依存しない汎用的なフォーマットを活用することにより、データ表現の幅が広がり、そしてデータの関係性の可視化（ex: PlantUML で UML 図を作成する）などが容易になるというメリットがあります。
ただしこの原則は、型を持たない動的型付け言語である JavaScript を前提としたものであり、静的型付け言語に対する適用には賛否あるように感じます。
最後に
冒頭の感想部分でも書いたように、「4つの原則」を実際にそのまま適用するにはするには工夫が必要ですし、議論の余地もあるように思います。
しかしながら、「コードとデータが混在している」ことがオブジェクト指向プログラミングの複雑性の原因の1つになっていることは大いにあると思います。そういった意味では、原則1から取り入れてみるなど、アイデアをかいつまんで日々の実装に活かしていけると良いなと思いました。
