Action设计模式下用trait实现公共方法是否为反模式？选trait还是接口？

结论先行：这种用法不属于反模式，反而能在遵循动作设计模式核心的同时，很好地践行DRY原则，是合理的代码复用手段。

为什么不违反动作设计模式？ #

动作设计模式的核心是将单一行为封装为独立的、可执行的动作类，每个类职责明确，能独立完成对应动作。Trait在这里只是作为代码复用的工具，用来抽离多个动作类中完全相同的实现逻辑，并没有改变动作类的单一职责，也没有破坏它们的独立性——MakeJuice和MakeCoffee依然是各自独立的动作类，只是复用了一段通用的代码。

Trait vs 接口：该怎么选？ #

• 接口的作用是定义契约，它只规定类必须实现哪些方法，但不提供具体实现。如果用接口来处理prepareWater，你还是得在MakeJuice和MakeCoffee中重复编写完全相同的代码，这直接违背了DRY原则，显然不是最优解。
• Trait的核心价值就是复用具体实现，刚好匹配你现在的场景：两个类有完全相同的方法实现，用Trait抽离后，既减少了重复代码，又能让每个动作类保持简洁。

使用Trait的注意事项 #

要避免Trait引入不必要的问题，需要注意边界：

• 确保Trait只封装无状态、无依赖的通用工具方法，比如你的prepareWater如果只是单纯的烧水、装水操作，不依赖外部状态或其他服务，用Trait完全安全。
• 不要让Trait承载动作类的核心业务逻辑，核心逻辑依然要保留在各自的动作类中，保证每个动作类的职责清晰。

替代方案参考 #

如果对Trait的耦合性有所顾虑，也可以把prepareWater抽成一个独立的服务类（比如WaterPreparationService），然后在MakeJuice和MakeCoffee中依赖这个服务。这种方式更符合依赖注入的思想，但在这个简单的场景下，Trait的实现更轻量、更直接。

内容的提问来源于stack exchange，提问作者ssrsvn