📝

技術書読書ログ「データ指向プログラミング」

2023/04/29に公開

感想

データ指向プログラミング(DOP)はOOPとは全く異なる考え方のプログラミング手法で、一気に読み切れるほどワクワク・興奮させられた本でした。

特に印象的だったのが以下の2点。

どちらもOOPに慣れ親しんだ自分にとっては最初は違和感があったものの、原則が理解しやすくメリットも同意できる部分が多いので、割とすんなりと受け入れることができました。

今までOOPを前提とした設計・コーディングに囚われていた自分に気づかされ、プログラミングに対する視野が広がったと感じています。もっと深く学びたいと思わせてくれる内容でした。

データを第一級市民(first-class citizen)として扱うことで、複雑さを軽減し、変化に強いプログラムを作るための手法。

データを第一級市民として扱う方法は、以下の4つの原則に従う事。

ルール
- カプセル化をしない
- コードはstaticでステートレスなメソッドとして定義する
  - データは全て引数として渡す
メリット
- コードが再利用しやくすなる
- ユニットテストしやすくなる
- システムがあまり複雑になりにくい
デメリット
- どのコードがどのデータにアクセスできるのかを制御できない
  - 原則3を適用することで、このデメリットは軽減される(イミュータブルにすればデータの安全性は保証される)

ルール
- データをクラスで表現しない
- 基本は文字列をキーとした文字列マップと配列で表現する
  - Set,List,Queue,Treeなどの汎用的なデータ構造も使える
メリット
- コードもデータ構造も汎用的で柔軟になり、変化に強くなる
デメリット
- コンパイル時のエラー制御ができない
  - 原則4を適用することで実行時のエラー制御ができるので、このデメリットは軽減される
- IDEの補完機能が使えない
  - 原則4を適用すること軽減されたり、今後のIDEの進化で解決される可能性がある
- 静的型付け言語だと、キャストが必要になることがある

ルール
- データを変更したい場合は、データの新しいバージョンを生成する
  - 例えば、配列の要素を変更したい場合は、新しい配列を生成する
- ライブラリを使う事で、効率的で利用しやすいイミュータブルなデータ構造を利用可能
メリット
- データの安全性が保証される(並列処理でも)
- コードの振る舞いが予測しやすくなる
デメリット
- ほとんどの言語でライブラリを使わないかぎり、効率的でイミュータブルなデータ構造を扱えない

ルール
- データの構造やデータの型を定義してバリデーション等をしたい場合は、データスキーマをデータ表現とは切り離して定義する
  - 本書では、JSON Schemaを利用している
  - データスキーマもマップ(辞書)として定義することで、内部構造の一部を切り出したり、再利用することも可能
メリット
- 検証すべきデータ、タイミング自由に選択できる
  - おすすめ
    - 外部のデータソースから取得したデータは検証する
    - 送信データを厳格にして、受信データは柔軟にする
    - システム内のデータ検証は、開発しやすさを目的にする
      - 本番環境では検証処理をしないようにしておく(パフォーマンスのため)
      - 関数の引数の検証をするのは、単体テストの対象になるような関数だけ
- 高度なデータ検証条件を利用できる(正規表現など)
- データモデル図や、単体テストのデータを自動生成できる
デメリット
- データとスキーマの結びつきが弱いので、データ検証の取捨選択を開発者が決めないといけない

DOPはClojureの基本原理をベースにして、それらを他のプログラミング言語に応用する方法を形式化したもの
- なのでDOPはプログラミング言語には依存しない(とはいえ、動的片付け言語の方が向いている)
情報を転送する場合、情報の詳細を特定する表現(クラスでマッピング)は不要で、単にデータをそのまま転送するだけ(汎用的なデータ構造)で十分