这不是框架带(或缺乏)有关,但一个Scalish此举将注入该协会作为一个函数,而不是作为一个地图。斯卡拉地图也是一个功能。的T
鉴于枯燥的类型令牌和实例相关联:
scala> object Types extends Enumeration { val AType, BType, CType = Value }
defined object Types
scala> import Types._
import Types._
scala> trait T { def t: String }
defined trait T
scala> case class A(t: String = "a") extends T
defined class A
scala> case class B(t: String = "b") extends T
defined class B
scala> case class C(t: String = "c") extends T
defined class C
并配有功能使用它的应用程序:
scala> trait AnApp { val types: Value => T ; def f(t: Value) = types(t).t }
defined trait AnApp
然后注入其作为地图:
scala> object MyApp extends AnApp { val types = Map(AType -> A("a1"), BType -> B(), CType -> C()) }
defined object MyApp
scala> MyApp f BType
res0: String = b
或模式匹配匿名函数:
scala> object AnotherApp extends AnApp { val types: Value => T = {
| case AType => A("a2") case BType => B() case CType => C() } }
defined object AnotherApp
scala> AnotherApp f CType
res1: String = c
实际上它是使用def
更方便:
scala> trait AnApp { def types: Types.Value => T ; def f(t: Types.Value) = types(t).t }
defined trait AnApp
scala> object AnyApp extends AnApp { def types = {
| case AType => A("a2") case BType => B() case CType => C() } }
defined object AnyApp
你不要用VAL拿到类型推断,但我似乎记得他们想补充一点。
也许这是因为我从来没有使用DI框架,但是我不清楚最终目标是什么。为什么你需要测试这是什么类型的通知器?为什么不把它变成黑盒子特质? – Owen
@Owen我有这个特质的多个实现,每个都处理不同类型的通知。还有其他方法可以处理这个问题,但使用地图是最高效的方法(与每次迭代调用'supports'方法或类似方法相反) –