DRYは重要だけど単一責務原則は気にしたことないな。そもそもインスタンスが副作用を内包するという設計が間違っていてimmutableなデータ型と副作用のない静的関数すべき
共通化しすぎて死ぬかバラバラすぎて死ぬかの二択を迫られる地獄の選択肢で草
大体は良好な保守性を実現する為の手法論だから、自身の環境でどちらがより保守性が良くなるかを考えて採択するのが良いかと。保守を考慮しなくて良いなら動けば良い。
それ悩むところか？仕様変更による修正タイミングや発生条件が同じなら「同じもの」、それらが違うなら責務が違うという事。
ただのテクニックに「原則」と付けてしまったのが良くないと思う。思考停止して警察化してしまう。
まず対立していると考えるのがおかしいのでは？
これをわかっているエンジニアは少数派という現実👼下手すれば設計のオーバースペックに。単一アクターの原則の方がいいと思う。オーバースペックになりにくい
もうこんなことで悩んでる時代じゃないってのに、理解した上であえて商売のために言ってんのかね。そうじゃなければ心底馬鹿野郎だと思う
なぜそんなに難しく考えてしまうのか？
DRYのために、if (isPatternA) doA() else doB()みたいなのが散らばるクラスを何度も見てきた。
未来の予測なんじゃないですかね？
DRYと単一責務って対立しなくね？DRYにすることが単一責務を促すと思うし、逆も然り
SRPは結局巨大クラスはやめてねという原則なんだろうけど変更理由とかアクターとかを基準にするのは成功してない気がする。凝集度とかを使った方がよさそう
なぜ、DRY原則 vs 単一責務原則(SRP)の優先度判断は死ぬほど難しいのか？
DRYは重要だけど単一責務原則は気にしたことないな。そもそもインスタンスが副作用を内包するという設計が間違っていてimmutableなデータ型と副作用のない静的関数すべき
共通化しすぎて死ぬかバラバラすぎて死ぬかの二択を迫られる地獄の選択肢で草
大体は良好な保守性を実現する為の手法論だから、自身の環境でどちらがより保守性が良くなるかを考えて採択するのが良いかと。保守を考慮しなくて良いなら動けば良い。
それ悩むところか？仕様変更による修正タイミングや発生条件が同じなら「同じもの」、それらが違うなら責務が違うという事。
ただのテクニックに「原則」と付けてしまったのが良くないと思う。思考停止して警察化してしまう。
まず対立していると考えるのがおかしいのでは？
これをわかっているエンジニアは少数派という現実👼下手すれば設計のオーバースペックに。単一アクターの原則の方がいいと思う。オーバースペックになりにくい
もうこんなことで悩んでる時代じゃないってのに、理解した上であえて商売のために言ってんのかね。そうじゃなければ心底馬鹿野郎だと思う
なぜそんなに難しく考えてしまうのか？
DRYのために、if (isPatternA) doA() else doB()みたいなのが散らばるクラスを何度も見てきた。
未来の予測なんじゃないですかね？
DRYと単一責務って対立しなくね？DRYにすることが単一責務を促すと思うし、逆も然り
SRPは結局巨大クラスはやめてねという原則なんだろうけど変更理由とかアクターとかを基準にするのは成功してない気がする。凝集度とかを使った方がよさそう