Scala蛋糕图案和依赖性碰撞

假设我们有以下特征(有2个实现)：

trait HttpClient {
  def get(url: String)
}

class DefaultHttpClient1 extends HttpClient {
  def get(url: String) = ???
}

class DefaultHttpClient2 extends HttpClient {
  def get(url: String) = ???
}

和以下两个蛋糕模式模块(在本示例中,它们都是依赖于我们的HttpClient功能的API)：

trait FooApiModule {
  def httpClient: HttpClient        // dependency
  lazy val fooApi = new FooApi()    // providing the module's service

  class FooApi {
    def foo(url: String): String = {
      val res = httpClient.get(url)
      // ... something foo specific
      ???
    }
  }
}

和

trait BarApiModule {
  def httpClient: HttpClient        // dependency
  lazy val barApi = new BarApi()    // providing the module's service

  class BarApi {
    def bar(url: String): String = {
      val res = httpClient.get(url)
      // ... something bar specific
      ???
    }
  }
}

现在,当创建使用这两个模块的最终应用程序时,我们需要为这两个模块提供httpClient依赖关系.但是,如果我们要为每个模块提供不同的实现呢？或者简单地提供不同的依赖配置的不同实例(例如使用不同的ExecutionContext)？

object MyApp extends FooApiModule with BarApiModule {
  // the same dependency supplied to both modules
  val httpClient = new DefaultHttpClient1()

  def run() = {
    val r1 = fooApi.foo("http://...")
    val r2 = barApi.bar("http://...")
    // ...
  }
}

我们可以在每个模块中以不同的方式命名依赖关系,使用模块名称作为前缀,但是这样做并不麻烦,而且如果我们自己没有完全控制模块,那么它们将不起作用.

有任何想法吗？我是在曲解蛋糕模式吗？