将 Spring 抽象工厂模式转换为 scala

Question

在 Spring 中，我有一个控制器，一个提供该控制器可以访问的方法的服务接口。控制器调用服务的各种实现方法。

在 scala 中实现相同的“设计分离”是正确的实现： 定义 scala 控制器，定义充当服务接口的 scala trait。定义一个扩展此特征并提供服务实现的新类。然后控制器将实例化这个新类并调用服务方法的各种方法实现。

这是好的设计还是在实践中如何使用 Spring MVC？

Answer 1

正如其他人所评论的那样，“好的设计”是一个灵活的概念，取决于其他因素。我不会加入讨论，而是提供我们方法的概述。

虽然我们选择了 Jersey 而不是 Spring MVC，但我们从传统的 Java 和 Spring webapp 开始。后来，我们用 Scala 重新编码，进展顺利。我们特意保留了类 Java 风格的 Scala——这可能看起来不酷，但效果很好，而且很容易培养新同事。

然后我们决定放弃 Spring，连同它的 XML 和整个传递依赖关系。这很容易，因为我们已经有一组服务和控制器，它们都是具有构造函数注入依赖项的类（当然都是 TDD）。我们所要做的就是编写一个新的 Bootstrap 类来实例化服务和控制器，在每个构造函数参数列表中提供必要的具体类。方便的是，Bootstrap 类本质上是将原始 Spring 接线音译为（非常简单的）Scala。 Bootstrap 类在应用启动时从 web.xml 启动。 （使用过 Pico Container 的人都会熟悉这种方法。）

在我们的例子中，我们不需要在服务层中过多地使用特征；由 TDD 驱动的具体类的简洁设计就足够了。但如果有必要，我们的方法也适用于服务的可插拔抽象。

现在我们有了一个除了 web.xml 之外没有 XML 的 web 应用程序，完全在 Scala 中，因此它易于导航和修改，并且外部依赖项要少得多。这对我们非常有效。

Answer 2

“好的设计”是相当主观的，对于每个程序员来说，“好的设计”的含义会随着时间而改变。大多数人认为有几件事是最佳实践，但即使是最佳实践也存在冲突。我个人的观点是，程序员应该继续学习这些最佳实践，更重要的是不断塑造他的代码，直到它达到适合这种情况的最佳形态。然而，随着程序员不断学习，它的“最佳”形状也在不断变化。

我不能告诉你在你的情况下什么是“好的设计”设计，因为我不知道情况。最重要的是，我不是你，所以我的“好设计”对你来说并不是最好的。我建议您通过一些问题自己找到它：

• 你为谁编程？
• 您的代码可以存活多久？
• 谁来维护您的代码？
• 您想创建自动测试并愿意为此更改您的设计吗？
• 您是否需要多个单一原则的实现？
• 此时您觉得哪种风格适合您？
• 代码多久更改一次？
• 您是要考虑未来，还是只创造当下需要的东西？
• 您喜欢使用哪些库？
• 您想花多少时间？