将Service作为参数传入POJO是否属于不良编程实践？

结论 #

能通过构造器将Service传入POJO，但是否属于不良实践，完全取决于这个POJO的职责定位。

合理的场景 #

如果SomeImplementation本身是带有业务逻辑的类（比如需要处理业务流程、调用Service完成操作），只是因为动态创建、不需要全局单例等原因没被Spring管理为Bean，那么通过构造器传入Service是完全符合依赖注入思想的：

• 遵循了依赖倒置原则：POJO依赖的是AnotherService的抽象（假设它是接口实现），而非具体实现类
• 避免了硬编码依赖：不会在POJO内部直接实例化AnotherService，降低了耦合度，也方便单元测试（可以传入Mock对象）

需要避免的场景 #

如果SomeImplementation是纯数据载体类（仅用于封装数据，只有get/set方法，无业务逻辑），此时传入Service就属于不良实践：

• 违背了单一职责原则：纯POJO的职责应该是数据封装，持有Service会让它变成兼具业务逻辑的类，增加不必要的复杂度
• 可能引发问题：比如POJO需要序列化时，持有Spring Bean（通常不可序列化）会导致序列化失败；同时也会让POJO的复用性下降

结合示例代码的分析 #

你的示例中，SomeImplementation在构造器中直接使用AnotherService，说明它本身带有业务逻辑，这种场景下的做法是合理的，但需要注意两个细节：

• 确保AnotherService是线程安全的：Spring默认的Service是单例，只要本身没有可变状态，就可以安全地被多个SomeImplementation实例复用
• 不要让POJO长期持有Service引用：如果POJO的生命周期很长，或者需要被序列化，持有Service可能引发资源泄漏或序列化异常

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