yosuke_furukawa:相性が良いか悪いかで言えば、違うパラダイムから来てるのでそのまま組み合わせようとしても相性は悪そうに思えます。どちらかのパラダイムに合わせて書き換える必要があると思いますが、関数型プログラミングで書かれた Google Client API 等のライブラリを DI コンテナ内部に閉じ込めて利用するのはそこまで難しくないように思えるので、そのように変換した上で、 DI コンテナを使い続けていただいてよいと思います。 そもそもライブラリの設計とアプリケーションの設計ではケアする領域が違います。ライブラリの設計は状態や状態を変更することによる副作用を持たないほうがアプリケーション側で組み込みやすいです。なので、関数型の考え方を Google API クライアントが持ってくることは理にかなっている気がします。 アプリケーションの設計では、どうしても状態を管理する必要があり、それをどうやってチーム全体でわかりやすい形で管理するかが一個の技術トピックです。チーム全体が DI コンテナのが使いやすいと思うのであれば、それを変える必要はないと思います。これはチーム全体でどういう形で状態を管理するのが簡単か、という問題になるので、ライブラリの設計が関数型だからといって、それに合わせて自分たちのやり方を曲げる必要はありません。

kmizu:相性というよりもDIコンテナ自体がそもそもオブジェクト指向プログラミング「言語」を前提として作られた技術であるということをまず書いておきたいと思います。「DIという考え方」は関数型プログラミング言語でも応用できるかもしれませんが、「DIコンテナ」はオブジェクト指向言語（特にクラスがある言語）特有のものと言えます。 　また、業界全体が徐々に関数型的に作られたライブラリなどに移行しているという潮流は確かに感じますが、別にオブジェクト指向プログラミングができなくなることを意味しません。というのは、そもそも関数型プログラミングとオブジェクト指向プログラミングは別に相反するものではないからです。 　たとえば、Javaでもセッターなどの副作用を使わないプログラミングスタイルは「関数型プログラミング」ですし、いわゆる関数型プログラミング言語でもオブジェクト指向プログラミングをすることはできます。パラダイムと言語はある程度独立しているということに注意してください。 　その上で言うと、DIコンテナという「ソフトウェア」は現状、オブジェクト指向言語（JavaやJavaScriptなど）でしか提供されていないので、DIコンテナがない言語ならその言語での作法を踏まえるべきです。一方、Javaで関数型プログラミングをするとしても、DIコンテナが有効であれば特に躊躇する必要はありません。DIという考え方の根底にある「依存性を外から注入する」という思想自体は別に関数型プログラミングと相反するものではありませんから。　 　プロジェクトでDIコンテナを使わないという方針で行くのならそれに従うべきだと思いますが「DIコンテナ」について特別避けようと意識しなくても良いかと思います。