Question

Cake Pattern article建议将特征用作命名空间：

trait UserRepositoryComponent {  
  val userRepository: UserRepository  
  class UserRepository {...}
}

trait UserServiceComponent {this: UserRepositoryComponent =>   
  val userService: UserService    
  class UserService {...}  
}

class Context extends UserServiceComponent with UserRepositoryComponent {  
  val userRepository = new UserRepository  
  val userService = new UserService  
}

但是，如果我们可以执行以下操作，我们是否真的需要这些“命名空间特征”（UserServiceComponent和UserRepositoryComponent）？

trait UserRepository {...}

trait UserService {this: UserRepository => 
  ...
}

class Context extends UserRepositoryImpl with UserService

所以，我的问题是我们何时以及为什么需要Cake Pattern中的“命名空间”特征。

Answer 1

您的方法有两个缺点：

Context承担了太多责任，混淆了UserRepository，UserService等方法;
在第一个片段中，您可以控制初始化的顺序，或者为某些组件延迟它 - 例如，您可以userRepository lazy val，如果您愿意，可以显着简化测试仅测试userService（因此，不想引导整个基础架构）;

虽然我不推荐它，但在第一种情况下，您也可以在运行时更改注入实体（使用var s）。

Answer 2

与任何模式一样，当您使代码更清晰/更易读/更易于维护/更易于测试时，您需要它。

在这种情况下，您可能希望为测试目的创建备用上下文，替换“生产”版本中使用的部分或全部组件 - 更容易实现的任务，以及更多自我记录的任务，如果通过文章中概述的模式完成。

正如瓦西尔指出的那样，这里关注的问题是一件好事（tm），几乎就是蛋糕模式的全部要点。

关于蛋糕模式的问题

2 个答案: