アカウント名:
パスワード:
これと似たような利点欠点があるように思った。
変更があっても関数インターフェイスを変えなくて良い → 未来に開かれた「変更に強い」とは思わない。
変更があるなら、インターフェイスにも変更が必要 → コンパイラがチェックしてくれるので、作業漏れが起こりにくい。結果、工数面で有利
上の懸念はあたっていると思う(高スキル少人数チームは例外として)
なるほど、たしかにそんな感じですね。
ダックタイプでいえば、duck.hogeとduck.fugaがあるとき、hoge/fugaの実装は期待するインタフェースの実装相当なのか、たまたま同じ名前にしちゃっただけなのか的なことがあるかな、みたいな。
# executeとdisposeだけあったときに、それぞれがこっちが期待する動作じゃなくて、SQL実行/テーブル削除する、とかされたらアウト!とかw
# 構造体は、余分なデータが乗ること自体まではいいですが、意図とズレてるか確認しずらいはありますやね...「引数をまとめて渡す」ためじゃなくて、引数として「ある意図の構造(微妙な変更はあり)を渡す」となってないとだめですね
ああそうか「意図しない動作」が考えられるから、こっちの方が被害が甚大ですね一見して正しいような動きとかも厄介だなw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
複数の引数を構造体1つで渡す (スコア:1)
これと似たような利点欠点があるように思った。
変更があっても関数インターフェイスを変えなくて良い → 未来に開かれた「変更に強い」
とは思わない。
変更があるなら、インターフェイスにも変更が必要 → コンパイラがチェックしてくれるので、作業漏れが起こりにくい。結果、工数面で有利
上の懸念はあたっていると思う
(高スキル少人数チームは例外として)
Re: (スコア:1)
なるほど、たしかにそんな感じですね。
ダックタイプでいえば、duck.hogeとduck.fugaがあるとき、hoge/fugaの実装は期待するインタフェースの実装相当なのか、たまたま同じ名前にしちゃっただけなのか的なことがあるかな、みたいな。
# executeとdisposeだけあったときに、それぞれがこっちが期待する動作じゃなくて、SQL実行/テーブル削除する、とかされたらアウト!とかw
# 構造体は、余分なデータが乗ること自体まではいいですが、意図とズレてるか確認しずらいはありますやね...「引数をまとめて渡す」ためじゃなくて、引数として「ある意図の構造(微妙な変更はあり)を渡す」となってないとだめですね
M-FalconSky (暑いか寒い)
Re:複数の引数を構造体1つで渡す (スコア:1)
ああそうか「意図しない動作」が考えられるから、こっちの方が被害が甚大ですね
一見して正しいような動きとかも厄介だなw