なぜ Go ではロガーをコンストラクタ DI してはならないのか

問題のある実装パターン 共通実装 以下のような applog パッケージ上のロガー実装を考えましょう。ここでは Go 標準の log.Logger をラップしていますが，様々な実装に拡張できることを想定しています。 package applog import ( "fmt" "log" "os" ) type Logger interface { Info(message string) Error(message string) } func NewLogger() Logger { return &logger{ inner: log.New(os.Stdout, "", log.LstdFlags), } } var _ Logger = (*logger)(nil) type logger struct { inner *log.Logger } func (l *logger)

[snowcrush]

ドキュメントにそういうことはするなと書いてあるのに… "Use context Values only for request-scoped data..."。記事の用途だとトレースIDだけContextに入れてloggerはグローバルから引っ張るだけで充分だと思う。

[strawberryhunter]

よくよく考えないで他の言語とか製品の流儀を持ってくるとだいたい失敗する。

[crexist]

go で納得いってないのがここなんだよな。log と言う本筋じゃない(無くても動作する)ものの為に Context を持ち回すのは違和感ある

[jnst]

リクエストコンテキスト専用のloggerを作ってるだけなのでcontextの作法として間違ってないですよ trace_idだけcontextいれるとlog出力するコード書くたびにloggerにセットするコード書く必要あるので糞だるい

[taguch1]

コンテキスト方式の実装は便利なのでなんか書き換えたくなるデメリットがない限りはこれでいいと思ってる。もっとシビアな環境で動くものなら全然違う実装にするけど。

[taiyow]

リクエスト固有の情報（TraceIDなどを入れたロガー）をctxに入れて持ち回ろうっていうGoとして至極まっとうな話を書いてるように見えるのに、なんで上からの指摘がついているのだろう…脊髄反射のコメを注目にあげないで

[craftone]

Goは抽象化してイケてる実装をするより、必要になったらリファクタリングすれば良いじゃない、な言語だと思うなー。シグネチャ変えてビルドエラーがなくなるまで呼び出し元を修正していけばまぁ動くし。

[Fluss_kawa]

新しい言語に挑戦する時にやりがちな前の言語の常識で失敗するってやつか。/エラー処理はpanicに頼らずちゃんとerrorを返して行ってなるべく上流でpanicさせるべきだと思うよ。

[tettekete37564]

Goが分からんと分からんな。

[NOV1975]

ダメだ。こういう単一トピック読んでも言語のツボわからんわ…Effective Goとか読破してからチャレンジしたほうが良さそうだな…

[nakag0711]

グローバルな関数でロガーを登録してグローバルな関数でそれを取得して使えばいいのでは

[zentarou]

contextはゴミ箱じゃないよ

[rgfx]

「(golangの)多くの関数は慣習として 「第1引数にコンテキストを受け取る」 という体裁に従います」

[asuka0801]

zapとかcontextに入れちゃうのが主流だけどrequest scopeではないloggerのような生存期間が長いobjectを contextに入れるのはモニョる。デフォルトではslog使いつつWithLoggerのような関数でloggerを置き換え可能にするのが良さそう。