clojure与google guice的等价物是什么？

我遇到谷歌guice，无法真正理解它和它做了什么，尽管它周围似乎有很多炒作。我希望从clojure的角度了解库，以及为什么clojure应用程序需要/不需要库，以及语言中是否内置了类似的东西。

由于Java的OO和类型系统，在不同的底层实现之间动态切换（例如为了测试（模拟）目的）可能很难管理。像GoogleGuice这样的库旨在用Java更优雅地处理这些问题

在Clojure和其他函数式语言中，可以传递函数，这使得使用不同的实现更加容易

在Clojure中有几种方法可以做到这一点：

• 使用您选择的函数作为高阶函数的参数
• （重新）将您选择的函数绑定到变量
• 将您选择的函数封装在闭包中，然后可以传递和调用闭包

的第12章有一些很好的OO模式示例，如依赖项注入，以及在Clojure中处理这些模式的替代方法

肖恩·德夫林（Sean Devlin）在Clojure中也有一个依赖注入的例子。不过，他的例子可能会选得更好。他没有在闭包中使用完全不同的函数实现，而是使用返回函数不同“版本”的工厂。但要点还是一样的

---

基本上，依赖注入是OOP中一个必要的邪恶模式，在FP中很容易解决（甚至不是问题）。

粗略的Clojure等价物仍在开发中。目前有两个图书馆正在开发中（截至10月12日）：Prismatic图书馆（尚未开源）和Stuart Sierra图书馆

---

注意，我认为Guice不仅仅是依赖注入。它为应用程序配置/模块化提供了一个框架。上述图书馆旨在实现这一目标。

感谢图书馆链接；它们看起来很有趣。我同意您的评估，Guice提供了一个不仅仅是依赖注入的解决方案，尽管我觉得Clojure支持的一些模式不需要那么多库，因为现在创建自己的库几乎是微不足道的（以Noir为例，看看defpage构造是如何工作的，它将自动加载命名空间和将页面集合聚合到一个由ref或atom包装的映射中）同意。我认为这就是Rich Hickey谈论“简单性”的原因为什么现在有那么多开发人员抱怨Spring框架配置的畸形。在任何情况下，一些Clojure应用程序（显然）已经变得足够大，需要这样的框架。