Go における FunctionalOptionPattern と MethodChaining について考える - pospomeのプログラミング日記

きっかけ FunctionalOptionPattern MethodChaining MethodChaining の問題点 Error フィールドによる解決方法 Error フィールドによる解決方法の問題 1. 各メソッドでエラーが発生しないような印象を受ける 2. エラーチェックを忘れそう その1 3. エラーチェックを忘れそう その2 FunctionalOptionPattern による解決方法 MethodChaining としての解決方法 Error フィールドの問題点は本当に問題なのか? どちらを使うべきなのか? まとめ きっかけこの記事を書くきっかけは以下のブログで、 MethodChaining の代わりに FunctionalOptionPattern を利用したという記事。 https://www.calhoun.io/using-functional-option

[pyamax]

なるほどなぁ。

[ono_matope]

おおっ。個人的には、記述/管理コストは明らかにFOPの方が高いので、どうしても必要な理由(すごい拡張性とか、構築過程でのエラーとか)がなければチェーン推奨ですかねー。

[onefootinthegrave]

メソッドチェインしないのがgoのジャスティスってことではないのかな

[daichirata]

ジェネリクスあればEitherとOptionみたいな話になれたかもしれない

[restartr]

今回のgormの論点でいうとFirst/Findはチェインから外して関数化してしまうのが良い気がしました。クエリビルドとクエリ実行は異なる手続きという見方で。 / あとgormではdb.Scopes()がFOパターンに近いアプローチですね。

[threetea0407]

言語に表現力が足りないのをどうにか頑張るみたいなのは大変そう

[mackee_w]

MethodChainingに出来る出来ない処理もあるけど、MethodChainingだと一行にまとめられるのでSQLと対比しやすとか。 / 拙作のORM https://github.com/mackee/go-sqlla では.First()とかがerrorを返すのを採用してます

[yosuke_furukawa]

めっちゃわかるし、最近悩んでもいた。