エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

『現場で役立つシステム設計の原則』　増田亨さん　を読んだ。「データしか持たないデータクラスは作らない！」

Java API 設計

こちらの本を読んででのレポートです。


複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる！
…が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ？　…と言われると、うまく言語化説明できない。

そんな私にたくさんヒントを与えてくれた本でした。
なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。

このブログに書いたことをまとめると・・・

  • 修正が大変なのはロジックが分散しているから
  • データとロジックをひとつのクラスにまとめるとロジックが分散しない！
  • じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき…　と思ったら、そうでもない？

この本のすごいところ

こういうコードは修正が大変ですよね。
だから風にリファクタリングしましょう！

…と、身近なイケていないコードのリファクタリングの話を読んでいたはずが、
いつの間にかドメイン駆動な設計の話に移っていきます。

ドメイン駆動設計の部分はエリック・エヴァンスの所謂DDD本をベースにしており、


「あー　あの本で見た。よくわからんかったけどとりあえず見た。」

という事柄が、随分噛み砕かれ、理解しやすく書かれています。
なのでエリック・エヴァンスに勝てなかった方には大変オススメ。
もちろんエリック・エヴァンス　誰それ？　って方にもおすすめの一冊です。

ソフトウェアの変更が大変なのは「設計」が悪いから　（第１章より）

ソフトウェアの変更は大変。

  • どこに何が書いてあるかを理解するまでに、調査に時間がかかる
  • ちょっとの修正なのに、変更すべき箇所があちこちに散らべっている
  • 慎重に修正したのに、思わぬ副作用に苦しむ


こういった変更が大変なプログラムは以下のような特徴がある。

  • メソッドが長い
  • クラスが大きい
  • 引数が多い


ならばリファクタリングしましょう。

  • わかりやすい名前を使う
  • 目的ごとに変数を用意する
  • メソッドを独立させる
  • 異なるクラスの重複したコードをなくす
  • 狭い関心事に特化したクラスにする

ここまではおそらく、ほぼ万人に受け入れられる、「当たり前のこと」ではないでしょうか。
うんうんそうだよね、と読める内容。

ところがここからじわりじわりと、人によっては「お！？」と思うような内容が書かれています。

値オブジェクト（Value Object）を用意する。基本データ型を使わない。

  • 数量を扱うために、Quantityクラスを作り、1以上100以下の様に制約も記述する。マイナスや非常に大きな値もの取りうるintをそのまま使わない
  • 電話番号を扱うのに、フォーマットのルールまで定めたTelephonNumberクラスを作る。Stringをそのまま使わない
  • 値オブジェクトを作ることで、業務の用語がプログラム中に現れるため、変更の際の調査が用意になる。『業務に関係するデータとロジックを閉じ込めておくことができる』
  • 値オブジェクトはImmutableに。1つの変数を異なる目的に使うような、変数の引き回しを防げる

そんないちいちクラスを作るなんてコード量が多くなるだけ…　という意見が出てきそうなところです。
実際、私が今まで仕事で見てきたプログラムでは、ここまで徹底して値オブジェクトが作られているものは見たことがありませんでした。

コレクションオブジェクトを用意する。配列やコレクションを表に出さない。

  • ループなど、コレクションを扱うコードは複雑になりがち。プログラムのあちこちに散らばり始めると読みにくくなる
  • 専用のクラスに閉じ込める。例えば、Listを直接表に出さないで、Customersというクラスを作り、そのインスタンス変数としてListを持つ
  • Immutableにするため、インスタンス変数をそのままGetterで返さない。別のコレクションを作り直して返す
  • コレクションに対する処理（全要素を返すとか、追加するとか、特定の条件のもののみ返すとか）は全てクラス内にメソッドとして実装

確かに、Javaでは8以降Lambda式が導入され、コレクションに対する処理の記述力が高まりましたが、だからこそ（？）複雑なStreamによる、一見するとよくわからない処理がかえって増えたようにも感じていました。
この方法にすることで、強制的に各処理に名前をつけざるを得なくなるため、可読性は高まりそうです。

一方で、慣れないと、Customers→Listの構成が冗長に感じたり、
「一個のインスタンスだと思って蓋を開けたら実はリストだった。びっくりした。」
ということもありそうに感じました。

データとロジックを一緒に置く　（第3章より）

この章の主張は

  • データとロジックを別のクラスに分けることがわかりにくさを生む
  • データと機能が分離していると…
    • 同じ業務ロジックがあちこちに重複して書かれる
    • どこに業務ロジックが書いてあるか見通しが悪くなる

という内容。

データとロジックはセットで。　という縛りを作ることで、自然にロジックが書かれる場所が定まり、どこに何が書いてあるのかわからなくなる事自体を防ぐ、という話です。

でも、Javaにおいて、データだけ持つデータクラス（＝DTO、Entityクラス、JavaBeans、…）はよく見る手法…なのですが、

  • Javaはオブジェクト指向であり、データクラスはふさわしくない
  • データクラスが広まったのは、Javaが業務サービスに導入された当時、COBOLやCなど手続き型言語の設計方法や開発方法が踏襲されたため
  • J2EEやStrutsはこの流れで生み出されてしまった

と、なかなか衝撃的なことが。StrutsはともかくJ2EEまで否定されるともはや、「Javaらしさとはなにか」というのもよくわからなくなりますが（笑）

※　とはいえ、ここまではっきり言っていただいたところで、始めてStrutsにふれた時に
「俺の思ってるオブジェクト指向となんか違う…」
「Logicクラスって何？？」
と感じた原因がわかったように思えます。

メソッドをロジックの置き場にする（＝ロジックのないメソッド禁止）

  • getterのように単に値を返すメソッドはダメ。メソッドはもっと役に立つもので無くてはならない
  • もしgetterを見つけたら、getterを呼び出している側に注目。getした値を使って何かの「判断／加工／計算」をしているはず。その「何か」ごとデータを持つクラスに移動してみる

このようなリファクタリングを繰り返していくことで、徐々にロジックが「データを持つクラス」に集約され、ロジックが重複して実装されることがなくなる、としています。

なお本書の特徴として、はじめから上に挙げたような、完璧なオブジェクト指向で実装されることを要求していません。

実装当初はデータクラスや、ただのgetterを作るのは問題ない（そちらのほうが書きやすい場合がある）。一旦動くようになったあとで、このようなリファクタリングを繰り返していくことで、ソフトウェアの変更容易性を善くすることができる

と主張されています。

TDDと根底の考え方は一緒ですね。まず動かす。そしてリファクタリングする。

なお、TDDで一つ思ったのですが、はじめ、このようにクラスをまたいだリファクタリングを積極的に行う場合、
「『メソッドの振る舞いを記述したユニットテスト』は、テストそのものがリファクタリングの邪魔になるのでは？」
と、感じました。
しかし、もう一度考えてみると、

  • リファクタリング中に、ふるまいが壊されていないことが確認できる　→　大きなメリット
  • ユニットテストが書かれている時点でメソッドは小さく、テストしやすいもののはず。概ね、そのメソッドがそのままデータのあるクラスに移動するだけなので、テストの修正量は小さい　→　小さなデメリット

と、メリットがあったり、テストの修正が必要になるにしてもさほど大きな修正ではなさそう…　ということに気づきました。

メソッドは必ずインスタンス変数を使う

インスタンス変数を使っていないメソッドはそのクラスのメソッドとして不適切。ロジックの置き場を再検討するべき。

これは先程の、「データとメソッドは同じクラスに置く」と逆のことをいっています。
例えばこのようなメソッドです。

BigDecimal total(BigDecimal unitPrice, BigDecimal quantity) {
  BigDecimal total = unitPrice.multiply(quantity);
  return total.setScale(0, ROUND_HALF_UP);
}

このメソッドは引数から全ての値を得ており、インスタンス変数を全く使っていないため、このクラスに存在している明確な理由がないのだそうです。

このような考え方はしたことがなかったので、衝撃的でした。

Web APIの作り方（第8章より）

ここまでは一貫して、

  • ロジックはデータの近くに置く
  • はじめから完璧なプログラムは書けない。徐々にリファクタリングして良い設計にしていく

ということが主張されてきました。

ということは、Web APIによってサービス間を連携する場合も、以下のような主張になる　と思っていました。

  • データを使ったロジックはデータを提供する側のAPIに置く
  • APIを利用する側には極力ロジックを書かない

しかし、どうやらそう単純ではないようです。

例えば、データ上存在している誕生日から年齢を計算する　といった、計算ロジックをどちらに置くか　という問題について、

  • どちらに置くにしてもロジックを持つ側の負担が増える
  • ロジックをどちらのアプリケーションが管理すべきかで判断する

と書かれており、「データを持っている方に置くべき！」という論調ではありません。
それぞれのサービスを担当する人が違うことによって、一つのアプリケーション内で閉じた話とは、格段に難しさが増しているようです。


とはいえ、
例えば誕生日から年齢を計算する例の場合

  • 基本データ（ここでは生年月日）の形式や内容の変更が利用する側のコードに大きく影響する
  • 逆に、導出結果を渡すAPIでは、基本データの形式や内容に変更があっても利用する側への影響は少ない

とあります。

基本データを変更することになるのは普通、提供側の都合（あるいは他の利用者の都合）だと思うので、ロジックを提供側に閉じ込めておいたほうが修正が早く、またテストもしやすくなると、個人的には思います。
また、本書で一貫して述べられてきた、データとロジックを一緒にすることでロジックの分散を防ぐ、という内容に沿わせることを考えると、やはり、データを持っている側のサービスにロジックを書くほうが全体として適切な構成になるのではないでしょうか。

（逆にこれで統一しないのであれば、提供する側は徹底してデータしか提供せずロジックは持たない、というルールにするべきだと思います。
しかしこの場合、年齢が複数のサービスから使われる時に、ロジックの重複を避ける方法がないのです）


追記
著者の増田さんご本人からコメントいただきました！


ご本人がまとめられている書評一覧を発見したのでメモ。他の方の意見が参考になります。
たくさんの書評、ありがとうございます | システム設計日記