问题标签 [cake-pattern]

关于简单示例的问题：

假设我们有：

1) 3 个功能： f(d:Dependency), g(d:Dependency),h(d:Dependency)

和

2）以下函数调用图：f调用g，g调用h

问题：在h我想使用d传递的 to f，有没有办法使用 cake 模式来访问dfrom h？如果是，如何？

关于真实示例的问题：

在下面的代码中，我需要手动将Handler参数从

// TOP LEVEL , INJECTION POINT

至

//USAGE OF Handler

是否可以使用蛋糕图案代替手动穿线？如果是，如何？

我想知道在 Scala 中为 DI 使用函数和 Cake 模式之间的区别。我想出了以下理解，我想知道这种理解是否正确。

让我们想象一个依赖图。

1）如果我们使用函数作为构建块，那么图由作为节点的函数和作为边的参数组成。

2）如果我们使用特征作为构建块（如在 Cake 中），那么图由作为节点的特征和作为边的抽象成员组成。

那么蛋糕模式的目的是什么？为什么 2 比 1 好？这是当然的粒化。Graph-1 可以通过将函数分组为特征来简化，然后我们有一个更小、更易于理解的 Graph-2。相关概念的分组/聚类是一种压缩形式，可以产生理解（我们需要在头脑中保留更少的东西才能理解）。

这是一个不同的比较（Cake 与包系统之间）：

Cake 类似于将相关函数分组到包中，但它超越了这一点，因为使用名称空间（包/对象）会导致依赖关系被硬连接，Cake 正在用特征替换包/对象，import用自类型注释/抽象成员替换 s。包和 Cake 模式之间的区别在于，依赖项的实际实现可以使用 Cake 改变，而使用包时它不能改变。

我不知道这些类比是否有意义，如果没有，请纠正我，如果是，请让我放心。我仍在尝试围绕 Cake 模式以及如何将其与我已经理解的概念（函数、包）联系起来。

我正在尝试了解蛋糕图案。

我正在阅读有关它的博客。

该博客的示例代码是：

我可以通过删除来简化该代码Users：

它编译得很好。

1）为什么博客里的代码这么复杂？

2）这是使用蛋糕图案的惯用方式吗？

3) 为什么Users这个例子需要这个类？

4）蛋糕图案应该是这样的吗（看起来没有必要的Users课程？

5）还是简化版就好了？

我正在尝试实现类似代码的蛋糕模式，但我得到：

使用下面的代码。

可能是什么问题？

我查看了这个SOF 问题，但它似乎描述了一个不同的场景（或者我可能只是没有看到相似之处）。

我有一个特征，它代表了一些公开一些公共方法的模块（想想一个服务）：

然后，我有一个Y模块需要来自X. 的客户Y也需要来自 的一项服务X。但我不希望他们依赖 whole X，只依赖这一项服务。我想“导出”一项公开的服务。

这可行，但是有没有办法保持方法名称相同？

在我在 Internet 上找到的所有与 Cake 模式相关的文章中，我看到了单级依赖关系，这对我来说很清楚。

但是当我开始使用它时，我遇到了一个问题，我不能只在高级课程中使用服务，我需要在多个地方混合使用它。

例如，如果我有一个服务并且该服务与一组其他服务一起使用，并且该组中的每个服务都使用一个数据库，那么我尝试不从这组低级服务中直接访问数据库。我只在高级服务中进行了所有数据库查询。但在某些情况下很难。

通过这个例子，问题可能会更清楚：

我有一组评分，每个评分都使用一个数据库。我有一个 FriendsScoring，它使用使用数据库的评分之一。我希望能够仅将数据库实现与 FriendsScoring 混合，并且不要在较低级别的服务中复制它。

我看到一个好的（可能是）解决方案是通过隐式构造函数参数为低级服务提供实现。

我刚刚阅读了Jonas 关于 Cake Pattern 的著名文章，例如：

根据那篇文章，为了使用蛋糕模式，它需要作为内部类包装在一个特征中，例如：

所以我想知道：

1. 这是实现蛋糕模式的唯一方法吗？
2. UserRepository如果是这样，这是否意味着在设计诸如蛋糕模式之类的类时必须考虑到它（以便可以将它们包装在特征中）？
3. 如果答案是肯定的，是否有任何常见的做法可以将未在包装器中定义的类包含到基于蛋糕模式的设计中？（在概念上类似于适配器）

问题：我已经使用蛋糕模式构建了一个组件（特征）系统，它定义了一系列类型并协变地专门化它们（参见家族多态性）。然后我定义了一个组件，它定义了一些参与者和要在这些参与者之间交换的消息。

问题是蛋糕变大了，可能包括不可序列化的东西。结果是多个akka.remote.MessageSerializer$SerializationExceptions。

问题：

• 有没有办法在不使设计变平的情况下解决这个问题（即，同时保持蛋糕图案）？
• 我可以使用案例类writeObject实现自定义序列化吗？readObject
• 如何避免消息的“外部对象”序列化？

我最近了解了蛋糕图案以及和的用法之间的区别self =>（self:T =>请参阅此处）。这里提到的这些技术细节和真正的 Scala 代码之间的差异继续给我带来问题。例如，请参阅以下来自Inox 项目的代码片段：

总之，整个片段对我来说没有多大意义（这是代码中经常重复的模式），让我解释一下：

1. 这是什么语法？

val interpolator: Interpolator { ... }

到目前为止，我写了val name: Type = value，这里没有平等。

2. Trees.this.type应该是一个类型，但是什么类型呢？它应该在 Trees trait 中定义，并且this我打赌的trait Trees上下文与上下文不同（与问题 1 相关）。我还查看了文件插值器，但似乎没有类型元素。

3. 最大的线是protected val trees: Trees.this.type = Trees.this.

谁能解释一下这里发生了什么？

使用 self-type 进行依赖注入，导致暴露其他 trait 的 public 方法，破坏了单一职责主体。让我用例子来说话

我的Sample班级依赖于Output特质，当然我想在我的班级中使用Output特质方法。Sample但是通过上面的代码示例，我的Sample类公开output了并非来自其功能的方法并打破了Sample.

我怎样才能避免它并继续使用自我类型和蛋糕模式？