Togetter/min.tを安心してお使い頂くためのガイドラインを公開しました。

またまたValueObject、そしていよいよRoleについて

(課題1) "VO"って言いつつ「OOP一般」とほぼ同義になってる主張があったりしないか。この場合、"VO"で何がいいたいのか? (課題2) モデルレベルではデータと処理が強く一体的なのがあり得ないのはDCIなどから概ね共通理解になってるが、それをJava言語等でimpl.するとき、どうすることができるか。
5
杉本啓 @sugimoto_kei

配賦計算やら外貨換算など計算処理が主題になる場合、Allocator とか CurrencyTranslator といった動詞的オブジェクトを作ることに、僕はあまり抵抗がない。配賦計算は、配賦される金額に属する訳ではないし、配賦割合に属する訳でもないと思うから。こういうのを嫌う人は多いのかな。

2019-10-12 18:57:11
杉本啓 @sugimoto_kei

配賦計算というコンテキストがあって、配賦対象金額や配賦率といった概念が生まれるのであって、その逆ではないと思うのな。DCI的に言えば配賦金額や配賦率は配賦計算というインタラクションにおけるロール。固有の振る舞いがあればそれを金額等に注入してもいいけど、そこまでする必要もないと思う。

2019-10-12 19:02:15
杉本啓 @sugimoto_kei

真面目に考えれば、すべての関数は独自のコンテキストを持つので、各関数について、すべての引数と返り値がそれぞれ別々のロールになる。普通は、そうしたロールを区別するのにクラスを設けることはせず、引数名などで区別するでしょ。

2019-10-12 19:05:18
杉本啓 @sugimoto_kei

理屈っぽく考えなくとも、ある程度の量のコードを書けば、業務領域の計算処理を値クラスに担わせるなんてアプローチは破綻する、ということぐらい見えてくると思うんですね。にもかかわらず、根強くそういう主張がなされるのは何故なのか、本当によくわからないです。思い付き? twitter.com/sugimoto_kei/s…

2019-10-12 19:39:47
杉本啓 @sugimoto_kei

例えば、値オブジェクトがオブジェクト指向設計の中核だとした場合、GoFのデザインパターンのすべては値オブジェクトと紐ついていないわけで、そういうものを選りすぐってパターン集にしたGoFの見識も疑われないだろうかw(まあ、GoFは、値オブジェクトパターンを含めるべきだったとは思うけど)

2019-10-12 20:31:19
たなかこういち @Tanaka9230

@sugimoto_kei この辺、ぼくはVO中心主義(?)を原則支持しています。関数のI/Oは全部ロールというのはその通りですが、やりたいのは、その全てのロールのSpec(仕様)をソースコード上で表現したい、さらには静的検査や形式手法的な証明の話に繋げたい。

2019-10-16 09:22:37
たなかこういち @Tanaka9230

@sugimoto_kei それをJavaというプログラミング言語でやるなら、「Javaのクラスを仕様表現のツールにする」という手法は使える、という判断。

2019-10-16 09:23:57
たなかこういち @Tanaka9230

@sugimoto_kei あるいは、、関数型を援用して、sortというメソッドやSorterという動詞クラスではなく、Sortedという演算結果クラスを作るというアプローチが(少なくとも理屈上は)あると考えています。 理屈としては関数の全I/Oを、修飾語付き名詞クラスで表そう、という話です。修飾語の部分は実際ロールです。

2019-10-16 09:29:31
杉本啓 @sugimoto_kei

@Tanaka9230 静的な型検査については理解できますが、「形式手法的な証明」が、この問題においてどのような有用性を持つのか、よく理解できませんね。具体的な説明を頂けるとありがたいです。

2019-10-16 09:58:15
かとじゅん @j5ik2o

僕もモジュールの構成要素としてVOを中心にしている。VOというよりか、抽象データ型を中心にしているという表現が近いかもしれません。 twitter.com/Tanaka9230/sta…

2019-10-16 10:33:32
かとじゅん @j5ik2o

この当たりの議論にはぜひともホワイトボードが欲しい…。VOに計算処理を固定的に紐付けた場合、データとロールの分離ができないでしょう?という話かな?? twitter.com/sugimoto_kei/s…

2019-10-16 10:38:56
杉本啓 @sugimoto_kei

@j5ik2o 「VOに計算処理を固定的に紐付けた場合、データとロールの分離ができない」という点はご指摘の通りなんですが、業務領域の計算処理を値クラスに担わせるという主張には、そもそもデータとロールという区別がないと思います。ロールというのは僕が持ち出した話なので。

2019-10-17 00:23:43
かとじゅん @j5ik2o

@sugimoto_kei なるほどー。渾然一体的な…。理解できました!

2019-10-17 00:28:54
たなかこういち @Tanaka9230

@sugimoto_kei だいぶ曖昧に用語を用いました。"形式手法"という語への期待値は、状態遷移といった動的振る舞いにおいて、遷移し得ない状態が無いか、未定義状態への遷移が生じてないか、などの不備を検出できたらいい、というところにありました。"型検査"はそこまでしない、という前提で。

2019-10-17 09:21:15
杉本啓 @sugimoto_kei

@Tanaka9230 どんな例を想定されているのか、いまひとつわかりません。増田さんの想定しておられる「ビジネスロジック」は、納期計算だとか引当済在庫数の計算といったものかと思っていますが、これらの計算の多くには、状態遷移は含まれないのではないでしょうか。

2019-10-17 09:29:03
杉本啓 @sugimoto_kei

@Tanaka9230 そもそも、増田さんが本件(ドメイン固有の値オブジェクトを作る件)に関連して形式手法や状態遷移について語っておられるのを見たことがないのです。それはたなかさんのご主張であって、増田さんのご主張の妥当性とは別のテーマではないですかね。似たような値オブジェクトの概念を含むにしても。

2019-10-17 09:39:03
たなかこういち @Tanaka9230

@sugimoto_kei その点は、全くその通りでした。 似たようなVOの考えを用いていたとしても、だからといって、そこに至るまでの思考や指向もきっと同じだろうと想定するのは、うかつでした。

2019-10-17 09:57:31
杉本啓 @sugimoto_kei

@Tanaka9230 ええ、私は、増田さんが言っておられること、書いておられることに対して論難しているのであって「増田さんが心中そう思っておられるだろうとたなかさんが考えておられること」に対しては、何の批判もしていません。理解できていないので批判のしようもないですし。

2019-10-17 10:00:58
たなかこういち @Tanaka9230

@sugimoto_kei 僕の言うところのものは、、業務プロセスの中に注文、出荷、売上等の各データがあって、それぞれの内のワークフローもあるし、全体の繋がりもある、それらが不整合起こさずにぐるぐるまわることをシステマティックに検査できたらいい、そのために処理(関数)のI/OのSpecをまず表現できたらいい、

2019-10-17 10:06:07
たなかこういち @Tanaka9230

まずもって、すえなみさんの指摘の通り、何でもかんでもVOと言い過ぎてるかもしれない。。。 「僕(の)がVOだ!」

2019-10-17 10:09:04
杉本啓 @sugimoto_kei

@Tanaka9230 たぶん、例示して頂いた方が理解しやすいと思います。雰囲気としてはわかるようでもありますが「処理(関数)のI/OのSpecをまず表現」とはどんなことか、それが目下の焦点である値オブジェクトの話とどうつながるのか、「システマティックに検査」とはどんな検査か、頭の中で具体的な例に紐つきません。

2019-10-17 10:12:42
たなかこういち @Tanaka9230

@j5ik2o @sugimoto_kei ここらへん、実装手段としては、Scalaのtrait、型クラスが知る限り最強かと。 あんまり解ってないけどObjective-C/Swiftのprotocolもいけるはず。

2019-10-17 10:20:44
かとじゅん @j5ik2o

@Tanaka9230 @sugimoto_kei そうですね。ScalaではDCIのコンセプトのまま実装できると思います。

2019-10-17 10:21:58
杉本啓 @sugimoto_kei

値オブジェクトにビジネスメソッドを生やしても、そもそも、問題に対する解決という点で重要な貢献がない。だから、少なくとも設計という文脈の中ではまったく中核的でないし、むしろ益がないのに構造を複雑にするのでやらん方がいいと僕は思うんだけど、みなさん、その辺の感じ方が違うのかなあ。

2019-10-17 10:32:19
残りを読む(36)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?