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

Question

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

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

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

Answer 1

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

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

• 你为谁编程？
• 你的代码能存活多久？
• 谁来维护你的代码？
• 您想创建自动测试并且愿意为此改变您的设计吗？
• 您是否需要多个单一原则的实现？
• 在这个时间点，什么风格适合你？
• 代码多久更改一次？
• 你想考虑未来，还是只创造现在需要的东西？
• 你喜欢用什么库？
• 你想花多少时间？

Answer 2

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

我们从传统的 Java 和 Spring webapp 开始，尽管我们选择了 Jersey 而不是 Spring MVC。后来，我们用 Scala 重新编码，进展顺利。我们特意保留了类 Java 风格的 Scala——这可能被视为不酷，但它运行良好且易于培训新同事。

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

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

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