问题标签 [cake-pattern]

我一直在阅读有关通过蛋糕模式在 scala 中进行依赖注入的信息。我想我明白了，但我一定错过了什么，因为我仍然看不到其中的意义！为什么最好通过自身类型而不是抽象字段来声明依赖关系？

鉴于Programming Scala TwitterClientComponent中的示例使用蛋糕模式声明这样的依赖项：

这比将依赖项声明为如下抽象字段有什么好处？

查看实例化时间，即 DI 实际发生的时间（据我所知），我很难看到 cake 的优势，特别是当您考虑需要为 cake 声明（封闭特征）做的额外键盘输入时

现在再次使用抽象字段，或多或少相同！：

我敢肯定我一定错过了蛋糕的优越性！但是，目前我看不到它以任何其他方式（构造函数、抽象字段）声明依赖项提供了什么。

我的开发大量使用了机器人腿绑定问题。我知道如何在 Guice 中解决它，PrivateModule但不清楚如何使用 Scala 的蛋糕模式来解决这个问题。

有人可以解释一下如何做到这一点，理想情况下，以乔纳斯·博纳（Jonas Boner）博客文章结尾处的咖啡示例为基础的具体示例？也许有一个可以为左侧和右侧配置的加热器，注入一个方向和一个def isRightSide？

我仍在尝试学习 Scala 的蛋糕模式。在我看来，它为您提供了集中“组件”配置的优势，以及为这些组件提供默认实现的能力（这些组件当然是可覆盖的）。

然而，它使用自我类型特征来描述依赖关系似乎混合了关注领域。组件（我认为）的目的是抽象出该组件的不同实现。但是组件中描述的依赖列表本身就是一个实现问题。

例如，假设我有一个充满小部件的数据库，一个允许我查找特定类型的小部件的注册表，以及使用注册表来处理小部件的某种算法：

现在你可以把它放在一些中央配置中：

如果我想更改为不同的数据库，我可以通过更改我的 mixin 轻松地注入它：

但是......如果我想混合一个不使用数据库的不同注册表组件怎么办？

如果我尝试使用不同的（非默认）实现对 RegistryComponent 进行子类化，RegistryComponent 将坚持我包含一个 DatabaseComponent 依赖项。而且我必须使用 RegistryComponent，因为这是顶级 AlgorithmComponent 所需要的。

我错过了什么吗？在我的任何组件中使用自类型的那一刻，我声明所有可能的实现都必须使用这些相同的依赖项。

有没有其他人遇到过这个问题？解决它的Cake-like方法是什么？

谢谢！

我想用<:而不用覆盖特征中的抽象类型=（就像这里的回答Scala Upper Bounds : value is not a member of type parameter）。

我想使用蛋糕图案，但这不起作用，我不明白为什么？

好的，这个例子运行了，但是在我的实际用例中，我想用<:而不是用覆盖类型。=似乎无法访问 t 函数，为什么？

返回错误value ping is not a member of S.this.T

我想使用 Cake Pattern 将某些软件系统的部分拆分为组件，以使其完全模块化，如本文中所建议的那样。在最简单的情况下，我想要一些可模拟的组件，比如日志、配置、数据库、脚本等，它们可能会相互使用。代码可能看起来像

在这里，数据库和配置组件（SomeConfig和SomeDatabase特征）是可插入的，并且可以根据需要更改为其他一些实现。他们的实现可以访问core同时包含数据库和配置的对象，因此数据库可以在需要时访问配置，反之亦然。

所以问题是：如果某些特征SomeDatabase变得很大并且不适合单个文件，如何将其拆分为单独的类，保留对core对象的访问权限？更具体地说，假设我需要将一些代码从连接方法SomeDatabase移到另一个文件中：

SomeClass是 SomeDatabase 如何工作的实现细节，所以我显然不想让它成为一个特征并将其混合到应用程序中。有没有办法提供对core对象的访问SomeClass？

一些相关链接：

1. Jan Machacek 的依赖注入与蛋糕模式
2. 真实世界的 Scala：Jonas Boner 的依赖注入
3. Scala 中的依赖注入：Adam Warsky 的扩展蛋糕模式
4. Martin Odersky 和 ​​Matthias Zenger 的可扩展组件抽象

def someA（in trait B）如何使用trait A与 in 相同C#MyType的B？（然后A#MyType =:= B#MyType）

它不编译：类型不匹配；

蛋糕图案的一大局限是它的静态性。我希望能够完全独立地混合可能由不同编码人员编写的特征。然而特征不会需要经常混入。在运行主应用程序之前，用户将有一个初始化屏幕，他们将在其中选择特征/程序集。所以我想到为什么不在用户选择选择模块中混合和编译选择的特征。如果编译失败，用户只会收到一些消息——不兼容的程序集或其他任何问题。如果编译成功，那么顶层 UI 模块将加载新编译的类以及程序集的预编译部分并运行主应用程序。请注意，在运行时初始化期间可能只需要编译一两个类。所有其余的代码都可以正常编译。

我对 Scala 很陌生。这是公认的模式吗？有什么支持吗？对于相对简单的依赖情况，不得不使用 Guice 似乎很疯狂。我可以在应用程序中轻松运行 Scala 编译器吗？我可以在内存中运行它并从内存中使用它的输出而无需创建不必要的文件吗？

注意：虽然看起来是动态的，但这种方法将保持100% 静态。

编辑它发生在 Microsoft 的 Roslyn 项目的驱动力之一是为 C# 和 Visual Basic 启用这种东西。但这似乎是一个相当大的项目，即使对于一个强大的微软团队来说也是如此。

我必须在使用蛋糕模式的项目中集成一些宏。这种模式使我们能够避免大量进口以及其他优势，因此我们希望保留它。现在，我们在主干外测试的一些实验性宏遇到了问题。首先，让我们展示一个名为 Cake 的虚拟系统：

APiece定义了一个类，BPiece应该是一个使用 APiece 定义的类的宏，最后，CPiece调用该宏。我说 BPiece 应该是一个宏，因为我无法为它编写实现代码。我尝试了几种方法，但总是因以下错误而崩溃：

阅读宏代码可以猜测将宏包含在静态模块中是必要的。有没有办法部署使用系统结构的宏？

似乎 Scala显式类型的自引用最常见的用法是在“蛋糕模式”中，其中模块的依赖项声明如下：

一般来说，暂时忽略蛋糕模式，,A可以引用任何类型级别的东西，例如类型参数：BC

...或抽象类型成员：

在这两种情况下，我们都不能写,abstract class Inner extends A with B with C因为和不知道是特征。这里需要显式类型的自引用。但是，我只见过带有特征的蛋糕图案：ABC

在这种情况下，我们可以abstract class Foo extends A with B with C直接写，如果我没记错的话，意思是一样的。我对么？如果不是，那么它们有何不同；如果是这样，为什么每个人似乎都使用显式类型的自我引用？

使用 Scala 中的一些较新的语言特性，可以实现可组合的组件系统并使用所谓的 Cake Pattern 创建组件，Martin Odersky 在论文Scalable Component Abstractions和最近的一次演讲中对此进行了描述。

Cake Pattern 中使用的一些 Scala 特性具有相应的 Haskell 特性。例如，Scala 隐式对应于 Haskell 类型类，Scala 的抽象类型成员似乎对应于 Haskell 的关联类型。这让我想知道蛋糕模式是否可以在 Haskell 中实现以及它会是什么样子。

蛋糕模式可以在 Haskell 中实现吗？在这样的实现中，Scala 特性对应于哪些 Haskell 特性？如果蛋糕模式不能在 Haskell 中实现，那么缺少哪些语言特性来实现这一点？