「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～

増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本

[suginoy]

サンプルコードを作るのは難しい。

[snowcrush]

批判が適切かどうかは対象書籍を読んでないので何とも言えないけど、ルールを盲目的に適用させるだけではパズルであって設計ではない、という主張はすごく同意したい

[w1234567]

俺がアホなせいで言いたいことが分からん、この例だと結局、SalesOrderというデータにロジック持たせてるだけじゃないのか？

[kamayan1980]

設計ルールその１「要件を確認しろ」、設計ルールその２「絶対に要件を確認しろ」って感じで日々設計してます。トラブルの種はだいたいそこにある。

[nunulk]

このサンプルコードが適切かどうかは分からないけど、ブール値を返すメソッドってたいてい if/else の出現を誘発するから、本当に必要か慎重に検討する必要あるよね

[otihateten3510]

「isDiscountableをQuantityに持たせてるの変じゃね？」って話でいい気がする。そのためにはルールが足りないよねっていう話。ただこの場合は「うるせぇ！YAGNIだ！」でも良い気もする。

[iwamot]

「受注ごとにその内容に応じて値引き可否が決まるという知識」を開示してよいかどうかだって、疑問の余地があると思うなあ。たとえば、値引き可否が過去の受注実績にも依存するようになったら、どうなのか。

[innx_hidenori]

“問題と解の関係性を、描いては消し描いては消ししながら重層的に深化させていくことが、そもそも、設計という活動の本来の姿”

[masatomo-m]

原則ってのは守破離の守で、守もできてないのに破や離をやろうとしてる人たちに話して響く内容と、守や破まで会得している人たちに響く内容は違うよねって話な気がする

[tolkine9999h]

業務ドメインや運用イメージを考慮に入れない設計は、結局役に立たないよね。

[cuttoff19]

"ルールに従ってパズルを解くとそれだけで達成感が得られるので、ルールを超える視点は頭の隅に追いやられてしまうという傾向が生じるのかもしれません。"

[nomnel]

“247users”

[kompiro]

「かぷせるか」とか「ぽりもーふぃずむ」とか、ドグマに縛られている感じがした

[ytRino]

いい話/増田氏に対する「ルール信奉」という評価はまさに自分の中の考えに名前をつけてくれた / 増田氏がテストコード書かない発言をしたときから氏に対して懐疑的になっています

[devrabi]

批判してる内容はわかるし、この書籍は突っ込みどころも多いんだけど、この書籍が主張しているポイントはそこじゃあないからなぁ…。

[iR3]

御意 “本番の試合中に健康体操をする人はいないでしょう。”

[Dai_Kamijo]

あとで、噛み締めながら読む //「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～ 現場で役立つシステム設計の原則批判-1 @phpmentorsさんから — 上條　大 (@Dai_Kamijo) Septe

[ghostbass]

何を開示して何を隠蔽するか、はドメインの要請によって決定されるのでこれは間違いとは言えない。ただSalesOrderがIsDiscountableを公開はしないと思う。

[jijyoron]

いやー、一読しただけじゃわかんないな…。

[k-holy]

“与件として与えられた問題を一定のルールの枠内で解くだけではなく、この場で何を隠蔽し何を開示すべきかといった新たな問いかけを生み出す”

[hdampty7]

ソースの全容が分からんからアレだけどこの場合は判定結果をMoneyクラスにも持たせるのが汎用的でッス。価格が値引きされているかどうかが必要になるのは価格を表示したり計算したりするときなので。

[kamegu3]

結果的に複数のクラスが割引条件に関係するとしても、独立して判定することができる部分については、そのクラスがメソッドを持っていてもいい気がする

[parasporospa]

SalesOrderの件に関してはこの記事に同意

[luccafort]

タイトルで批判と書いているけどぼくにはレビューという印象が強く残った。この本、書店で手にとってパラパラと読んでみたけどいまいち自分にはマッチしなかったのだけどその理由の一端がわかった気がする。

[pokuwagata]

続きも気になる

[turanukimaru]

SalesOrder にデータとロジックを一体化させてるので変わってないというか、書籍ではQuantityは単なる数量（とその制限）なので、金額に関わるメソッドは金額クラスにあるべきという話ではなかろうか。主題でなく設計ミス

[hatsu_mi]

言ってることはとてもわかるけど、対象読者の違いなのかなと思う。オブジェクト指向やったことない人にこの説明は多分伝わらない。

[yojik]

オブジェクト指向エクササイズ、HUNTERXHUNTERでジンがやっていたイボクリみたいなもんだから！