我准备喝koolaid :)
Play 正在迁移到 Google Guice (https://github.com/google/guice),所以我想我在这里别无选择,只能顺路顺势而为。
不知何故,我错过了一些东西。
我得到“不要调用我们,我们会调用你”的心态和依赖注入(inject)解决方案的核心原因 - 不那么脆弱和更可测试的代码。
然而,有时我想要的只是一根简单的牙签,并且觉得不需要烤蛋糕,或者更糟糕的是,我写了完整的烤蛋糕食谱,只是为了得到一个……
Scala,这种语言似乎使牙签工厂变得微不足道(Guice 的论点之一是 build 工厂的成本(在 Java 中)——所以对我来说,这个论点至少不在讨论范围内,但这并不能否定 DI 的其余部分我知道的问题)。
在 scala 中,您有一个伴侣 object
(对不起,有一个 Restful 闪回——我需要一点时间——好的,可以走了——哦,请怪奥德斯基因为这些词的组合而不是我……)。
对于牙签类:
case class Toothpick(color: Color)
object Toothpick {
def redPlease = {
Toothpick(Color.RED)
}
}
当然,您可以使用
apply
以及许多其他 scala 细节,只需引用 Toothpick
即可获得您想要的确切牙签“目的”:val myShinyRedToothpick = Toothpick.redPlease
所以在这种情况下
Toothpick
object
是即时工厂。让事情变得简单并不意味着它是正确的——它只是让它变得简单。
Google 的 Guice 的概述似乎是:一厂一统 .
好的-我可以忍受。他们得到了他们的第一个——他们拥有所有的土地——我们将永远是佃农。游戏结束。
我需要的是如何的牙签示例使用 一个Guice'd up工厂。我如何从 中获取我该死的牙签正常 请问Scala代码?
(就像我说的那样,我可能完全没有捕获重点......所以如果是这种情况,请随意 throw 任何需要让我朝正确方向看的猴子废话)。
PS:我不需要上课为什么 - 我只想要 中的一个如何 .
最佳答案
所以,嘿,这是一个复杂的 HOW-TO。 (注意:未经测试且完全愚蠢的代码)
public class MyComplicatedGuiceModule extends AbstractModule {
protected void configure() {
// does some configuration stuff
}
@Provides
@Named("RedToothPick")
ToothPick provideRedToothPick() {
ToothPick(Color.RED)
}
@Provides
@Named("WhiteToothPick")
ToothPick provideWithToothPick() {
ToothPick(Color.WHITE)
}
}
要在您的类(class)中使用它,您可以执行以下操作:
public class WildCleanToothService(@Named("RedToothPick") toothPick: ToothPick) {
}
现在,可以公平地争论:为什么会出现并发症?看看 Scala 代码使用了多少行?
对我来说,最大的好处是测试实际代码。它归结为:你如何测试你的伴生对象?如果它调用一些随机服务怎么办。我们将如何模拟该服务?能够插入依赖项使得单独和轻松地测试它们成为可能。
关于scala - 如何使用 Google Guice 的 @Inject 和 Scala/(Play 2.4.x),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31358727/