paradoxparanoicDRYは重要だけど単一責務原則は気にしたことないな。そもそもインスタンスが副作用を内包するという設計が間違っていてimmutableなデータ型と副作用のない静的関数すべき
2026/04/05 12:16
nguyen-oi共通化しすぎて死ぬかバラバラすぎて死ぬかの二択を迫られる地獄の選択肢で草
2026/04/05 17:31★
sgo2大体は良好な保守性を実現する為の手法論だから、自身の環境でどちらがより保守性が良くなるかを考えて採択するのが良いかと。保守を考慮しなくて良いなら動けば良い。
2026/04/05 17:51★★★★
tettekete37564それ悩むところか？仕様変更による修正タイミングや発生条件が同じなら「同じもの」、それらが違うなら責務が違うという事。
2026/04/05 18:05★★★
gabillただのテクニックに「原則」と付けてしまったのが良くないと思う。思考停止して警察化してしまう。
2026/04/05 18:23
stabuckyまず対立していると考えるのがおかしいのでは？
2026/04/05 18:48★★★
bfojこれをわかっているエンジニアは少数派という現実👼下手すれば設計のオーバースペックに。単一アクターの原則の方がいいと思う。オーバースペックになりにくい
2026/04/05 18:53
onesplatもうこんなことで悩んでる時代じゃないってのに、理解した上であえて商売のために言ってんのかね。そうじゃなければ心底馬鹿野郎だと思う
2026/04/05 19:35★
diveintounlimitなぜそんなに難しく考えてしまうのか？
2026/04/05 20:03
sumomo-kunDRYのために、if (isPatternA) doA() else doB()みたいなのが散らばるクラスを何度も見てきた。
2026/04/05 20:04
clairvy未来の予測なんじゃないですかね？
2026/04/05 20:33
short_tanuDRYと単一責務って対立しなくね？DRYにすることが単一責務を促すと思うし、逆も然り
2026/04/05 20:49
nakag0711SRPは結局巨大クラスはやめてねという原則なんだろうけど変更理由とかアクターとかを基準にするのは成功してない気がする。凝集度とかを使った方がよさそう
2026/04/05 20:55
pekee-nuee-nueeプロダクトが始まったときはDRYが強くて、サイズがデカくなって2人とかでは手に負えなくなってくると単一責務が効いてくるというような印象です
2026/04/05 23:26
mockmock9876小難しく書いてるけど、それって本当に同じもの？という問いをしてれば解消する話では…？
2026/04/05 23:51
PrivateIntMain変わるときはどうせがっつり変わるし、変わらなくていい終盤でがっつり変わるのは困る、ぐらいの心持ちでいたい。できるとは言っていない。
2026/04/06 00:03
hkdn理解しないまま魔法の杖を使いたい人達が大半だから。
2026/04/06 00:07
Ampelixとてもありがたい記事
2026/04/06 00:28
pmintZenn品質
2026/04/06 03:02