クリスマスのなんだか浮かれた電飾、いわゆる浮かれ電飾の本場といえば、やっぱりアメリカなのではないでしょうか。いや知らんけどイメージ的に。実際そのへんの家とかでもけっこうやってる浮かれ電飾ですが、なんらかの理由によりものすごくなってしまった電飾がつどった場所というのが、あちこちにちらほらあるという状況のようです。

たとえばサンカルロス市のとある通り。レッドウッドシティやサンマテオのちかくの、どちらかといえばちいさなパッとしない市ですが、なんだかすごいことに。おなじ場所に4年前にもいったのですが、ことしもいってみました。

まあそんなこんなで、すげーあかるいし、とにかくこう、すごい。人通りもおおく、車での見物客もおおくて渋滞しているし、まあすごい。

ときどき住人とおぼしき人々もみえ、住人たちはどうおもってるのかな……でもみてもらったほうがいい気分なのかな……などとモヤモヤしたり、すごかったです。

4年前とくらべると、だいたいおなじようなかんじで踏襲されていますが、細々とアップデートがあるようにおもいました。これを維持しつつ更新していくの、たいへんそうだなあ。

このやつとかも4年まえとだいたいおなじ構成でありつつ追加要素がいっぱいあるかんじだしなー。

あと4年前とくらべると、カメラの性能が格段にあがり、夜のちょっと暗いところでもきれいにとれるようになりましたね。Pixel2よいですね。

https://recruit-tech.co.jp/blog/2017/12/11/go_dependency_injection/

この記事をみた。ここからは個人的な雑感だけど、結論からいえばGoではここまでのDIは必要ないことがおおいとおもう。

DIがなぜ必要なのかというと、テストをしたいからだ。しかもたいていはユニットテストだとおもう。UserServiceとUserRepositoryみたいなのがあったとして、UserServiceの挙動をテストするために、UserRepositoryがある特定のふるまいをしたときのことをテストしたい、みたいなやつ。

Goのばあい、ユニットテストは元のコードとおなじパッケージに存在していて、テストコードは内部構造もしっているし直接さわれる。だからこんなに頑張ってビルダをそとからわたさなくてもいいことがおおい。

具体的には、たとえば

package user

type Service struct {
  repo Repo
}

func NewService(opts... ServiceOptions) *Service {
  return &Service{repo: initRepo(opts...)}
}

みたいなservice.goファイルがあるとすると、service_test.goファイルでは、

package user

func TestService(t *testing.T) {
  s := &Service{repo: mockRepo}
  ...
}

などのようにNewServiceをつかわずに初期化していい。

もちろんこのとき、初期化関数（NewServiceなど）じたいのテストができないという難点がある。でもこうした初期化関数はほんとうにインスタンスをつくるだけのような自明なものにすれば、テストする必要性はそれほどない。

もちろん、ほかにいろんなパターンがあるので、DIする必要がまったくないということはない。たとえば、インテグレーションテストの環境のために外部サービスをきりかえる、ということはある。ほんとうは外部のストレージサービスに接続するが、テスト用にはオンメモリな実装をつくって、テストデータでうごかしたいときとか。そういうばあいには、インタフェースをパラメータとしてうけとるような構造をつくってDIすることにはなるとおもう（ただ、ビルダが必要になるかはわからない。インスタンスをつくって渡すのでいいんじゃないかなあ）。ほかにも実際の実装モジュールがいろいろあって設定できりかえたいとか、DIしたいパターンはおおいとはおもう。

とはいえ、そのようにきりわけられるべきレイヤはそこまで大量にはならないので、こういうJavaみたいな壮大なDIフレームワークがほしいことは、あまりないんじゃないか。ふつうにmainでわたすとか、カスタマイズしたいときだけオプショナルなパラメータを指定するとか、そういうのであまりこまらないと、個人的にはおもう。といった雑感です。