我准备喝koolaid了:))
Play正在转移到Google Guice(https://github.com/google/guice),所以我想我在这里没有真正的选择,只能标记为骑行。
不知怎的,我错过了一些东西。
我得到了“不要打电话给我们,我们会称呼你”的心态和依赖注入解决方案的核心原因 - 更少的脆弱和更可测试的代码。
然而,有时候我想要的只是一个简单的牙签而且不觉得需要烤蛋糕,或者更糟糕的是还要写一个完整的烤制配方,只是为了得到一个......
斯卡拉,这种语言似乎使得牙签工厂变得微不足道(Guice的一个论点是建造工厂的成本(用Java) - 所以对我来说这个论点至少不在谈论桌面,但这并不能否定其余的我所知道的DI问题)。在scala你有一个伴侣object
(对不起有一个宁静的闪回 - 我需要一点时间 - 好好去 - 哦,并责怪奥德斯基的那些词组合而不是我...)。
Toothpick课程:
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工厂的牙签示例。如何从 NORMAL Scala代码中获取我的牙签?
(就像我说的那样,我可能完全忽略了这一点......所以如果是这样的话,就可以随意投掷任何猴子废话让我朝正确的方向看)。
PS:我不需要上课为什么 - 我只想在如何中找到一个。
答案 0 :(得分:0)
嘿,这是一个复杂的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)
}
}
要在课堂上使用它,你可以这样做:
public class WildCleanToothService(@Named("RedToothPick") toothPick: ToothPick) {
}
现在,公平地说:为什么复杂化?了解Scala代码使用 less 行的方式?
对我来说,最大的好处是测试实际代码。它归结为:你如何测试你的伴侣物体?如果它调用了一些随机服务怎么办?我们如何模拟服务?能够插入依赖项使得可以单独和轻松地测试它们。