BirthdayというValueObjectはありなのか？杉本氏（@sugimoto_kei）の考えのまとめ

杉本啓 @sugimoto_kei

@Tanaka9230 補足：主旨は、AgeCalcみたいなクラスを作るべきだということではないです。多くの場合それは過剰設計であり、単にPerson#getAge(現在日)でよいと思います。言いたかったのは、設計を突き詰めたとしても、Birthday クラスはたぶん必要にならないだろう、ということですね。

いわた @wonderful_panda

Birthday型を設ける目的って、Birthdayどうしの加減算みたいな無意味な計算をしてしまうのを防ぐとか、Birthdayを受け取るべき箇所で別の日付を間違って渡してしまうのを防ぐとかがメインではないの

qsona @qsona

この一連のツイートは非常に参考になります。クラスを何のために作るかとかの立場は他にもありそうですが、(最終的な答えがどうかよりも)この考えのプロセスはクラス設計する上で参考になるなあ twitter.com/sugimoto_kei/s…

杉本啓 @sugimoto_kei

@Tanaka9230 ① 基本的な考えは、最初のツイートに書いた通りです。僕は、誕生日は値集合ではなく、Personを定義域としDateを地域とする関数なので、値クラスとしてモデリングすることに違和感があります。モデルは私たちの認識の構造を出来るだけ素直に映すべきと思うのです。

2019-09-08 14:00:58

たなかこういち @Tanaka9230

@sugimoto_kei ありがとうございました！ まず、年齢計算という業務ルールとそれへの入力となる誕生日等の項目との依存関係についてよく理解できました。 たぶん、こっちならまだよい、という話になるかと思いました。 pic.twitter.com/OqKWyR1coV

拡大

たなかこういち @Tanaka9230

@sugimoto_kei 杉本さんの論旨の主要点はここにあると理解しました。

たなかこういち @Tanaka9230

元々Birthdayを持ち出したのは、fullName,firstName,lastNameの"getter"問題に関してある種の例示をしたかったからだった。Birthdayはよい例では無かったということだが、この点再Tryしたい。

杉本啓 @sugimoto_kei

@Tanaka9230 Ageという値クラスを設ける理由が（年齢計算以外に）存在するからAgeを作る。そのうえで Ageのファクトリーメソッドに年齢計算をやらせる。ということでしたら賛成です。年齢計算をやらせるためにAgeという値クラスを作る、のなら反対です。コードの字面（じづら）ではなく、目的適合性の話なんです。

杉本啓 @sugimoto_kei

@Tanaka9230 AgeであれBirthdayであれ、値クラスを設けるのは、値クラスを設けるメリットがあるからのはずで、年齢計算をやらせることはそのメリットには含まれないよね、ということです。年齢計算はutilクラスのstaticメソッドでも出来ますから。utilが大きくなってきたらAgeCalcクラスに分離すればよいだけだし。

杉本啓 @sugimoto_kei

値クラスを細かく作る話。発注を例にすれば、発注予定日、発注日、納期、納入予定日、納入日、検収日、支払締日等ある。これら全部を別のクラスにして何の意味があるのか。比較したり日数差を算出しようとすれば、全部、toDate()で変換やん。こんなの本当にやってるの？ twitter.com/sugimoto_kei/s…

杉本啓 @sugimoto_kei

@Tanaka9230 僕としては、Birthdayというクラスを設けることについて、基本的には、違和感を感じます。誕生日は、人の集合を定義域とし日付の集合を値域とする関数であって、値集合ではないと思うからです。

2019-09-07 09:12:48

杉本啓 @sugimoto_kei

静的型チェックで、納期計算みたいなビジネスロジックを堅牢に記述できるってゆうけど、結局そのビジネスロジックメソッドの中で、発注日とかを汎用の日付に変換して計算すんるんやろ？ それは、書き間違いのリスクを他の場所に移動してるに過ぎへんのちゃうか？

杉本啓 @sugimoto_kei

本当にこの「ビジネスロジックを生やした値オブジェクト」は、なかなかのアンチパターンだと思う。メソッド名にドメインの言葉が散りばめられて一見よさげにみえるので、ひっかかる人が多いだろう。