関数の多重下請けをやめよう。単一責任の原則と関数の"責任"について

「多重下請け構造は悪い」、これは世間的にだいぶ浸透してきた考えだと思います。しかし、プログラマは 多重下請けのコードを気づかぬうちに書いてしまうことが多々あります。 なんなら皆さんもついウッカリやってしまっているでしょう。 当然ながらコードベースでも多重下請けは良くありません。今回の記事では、多重下請けコードとは何か、その問題点、回避方法を解説します。 多重下請け構造になってるコードとは? 多重下請け構造になってるコードとは、タスクをたらい回しにしているコードです。 たとえばECサイトで注文するシーンを考えてみます。サーバーの実装はこんな感じです。 def 注文API(): 注文処理(price) 集計DBにログを送る() def 注文処理(price): 決済する(price) 履歴に保存する() def 決済する(price): if キャンペーン期間中だったら: 支払う(price

[dot]

問題点として指摘されているが、自分は関数につける名前が思い付つくか、というのを判断基準にすることが多い。名前が付けられないというのは関数が行う処理が意味のあるまとまりになっていない。

[mak_in]

コレに近い考えで、共通化のため、デコレーターパターンで、継承しまくるやつ。過去、6回継承してるやつに遭遇したことある。自称プログラム得意な人だった。その人しか良い生産性でメンテできなかったんだよな

[kobito19]

"「多重下請け構造は悪い」、これは世間的にだいぶ浸透してきた考えだと思います" そうか？まずこの前提が共有できてないと思うが。 "どの関数が何を担当しているか分からない" なのが原因なだけで委譲は普通にやるだ

[sisya]

主張は理解できるがどう実践すればとなる場面の一つ。個人的には自前の関数を回すのは基本2段までで、それ以上いくなら本当に必要なのかを一度考えるようにする。現実の行動でも3段越えると伝言ゲームの弊害が大きい

[auto_chan]

最初にやりたいことを名前だけつけた構造で空実装するとよいよね。ここは注文全体ここは商品ごとのループってレベルまで呼出構造を実装し、コメントかprintで詳細を書いて……あとはAIか部下に丸投げだガハハ！

[homarara]

これは多重下請けとかの問題ではなく、設計思想としてドメインをどう切り分けてるか次第では。

[nakag0711]

この種の関数は複雑なコードをモジュールやレイヤに分割した結果として出てくる。その場合はそうなるのが正しい。フロントエンド界隈は画面数は多くても本質的な複雑度が低いからこの辺り理解されにくくなってる？

[kazuau]

ひとりで色んなことをするのはやめて、分割して責任分担させるのだから、どっちかというと正しく多重下請けをさせよう、ではないだろうか

[remonoil]

感覚的だけど「あーはいはいこういうことがしたいのね」ってすぐ分かるように書く。アジェンダ・目次みたいな感じ / キャンペーン判定というか金額の決定は分けたい…

[tor4kichi]

トランザクション単位で主作用を書き下す方が見通しいいのはわかる。個人的にタイトルは単一責任の原則じゃなくて KISS（Keep it simple stupid）の原則の方がしっくりくるかも

[mohri]

（ブックマークコメントで議論が起こっているのが興味深い）

[shingo-sasaki-0529]

多重下請け自体は悪くない気がする。外から見て何を達成してくれる関数なのかがわかれば、その中で具体的にどういうプロセスで実施されているかを知る必要性はない場面は多いし。分解の粒度が適切かとかの話かな。

[lethli]

認可とかログとか一連の単位でまとめて処理されるべきことの有無によって変わってきそう

[igrep]

結局必要十分で簡潔な名前を付けられるかだよなあ。

[hiroshe]

このあたりのことについて詳しい本を知りたい

[hecaton55]

結局は見る人が構造を理解しやすい程度に切り分けされているかという問題に思える。分割統治する時の分割は気を遣う必要がある

[repon]

ずっと先まで見に行かないと何やっているかわからない関数の解読は、脳のメモリを食いつぶすなぁ

[Dai3gen4Anko]

言わんとする事はわかるけど、組み込み系はハード依存性でレイヤー分けしないと新しいハードに対応する時に破綻するのよ

[trace22]

多重下請けどころか無限下請けが大好きなプログラマ

[monorod]

単に関数の切り方がヘタクソなだけで多重下請け云々とはあんまり関係ないのではと思った。

[hatest]

最初のコードと最後のコードで「注文完了メールを送る処理」と「履歴に保存する処理」の処理順序が入れ変わってる。「タスク分割」が重要なポイントなのにその説明はざっくりでコード例も適当だとよくないよ。

[paradoxparanoic]

いや、この問題の本質は関数が副作用を持っていることで、全てのパラメータと結果を引数と戻値で受け渡しすればほとんど解決する

[jintrick]

なんか引っかかるんだが、本当にこれでいいのか？

[tanatana456]

変更時の影響範囲の狭さが一番大切だよな。雑な処理を書いてても影響範囲さえ狭ければ後からどうとでもなる。

[qawsklp]

なんでもやり過ぎは良くない...

[hogetax]

螺旋階段上ってる途中かな？先人が行ったり来たりしてるとこだよね...

[otherworld]

インタフェースとユースケース、ドメイン、実装の詳細の責務は確かに違うものなので、3層か4層のレイヤー化アーキテクチャを勉強してみた方が良いと思う。

[baronhorse]

油断するとファットコントローラーになりそうだな

[FreeCatWork]

にゃんてこった、関数たち多すぎにゃ！責任丸投げしてちゃダメだにゃ。自分の仕事は自分でせにゃ、そうすりゃにゃんとも平和なコードになるですにゃ。

[Phenomenon]

始点が違うけど関数が関数を呼び出す場合はなるべくプリミティブな関数だけに絞りたいよね。テスト書きにくいってなって気がつく事が多いかも。

[atsushifx]

OOPなら、クラス内のメソッドで問題が起きない気もする

[wwolf]

SLAP/SLA原則はもっと知られるべきである

[mushus]

多重下請け構造が悪いというより、どっちかと言うと名前と処理内容のズレが問題に見える。メールの例だと決済するで想像するのはお金の処理であってメールを飛ばすことでは無いので低凝集とは言える。

[gm91]

参考にする