使用类方法作为输入对象的setter，更新其字段违反了什么设计原则？

违反的核心设计原则 #

• 封装原则：面向对象的封装要求对象的内部状态（字段）只能通过自身提供的公共接口来修改，而非允许外部直接操作。示例中Data类的$someField、$anotherField被设为public（即便注释说明应当私有），SomeUseCase直接执行$data->someField += 5修改值，完全绕过了对象自身的状态控制逻辑。这破坏了对象对自身状态的管理权，无法在修改时添加校验、日志或其他必要逻辑。

• 命令-查询分离原则（CQS）：该原则要求方法要么是命令（修改状态但不返回结果），要么是查询（返回结果但不修改状态）。而updateData作为命令方法，修改的是外部传入对象的状态，而非自身或受控范围内的状态，导致隐式副作用——调用者传入$data时，无法直观预判调用方法后该对象的状态会被修改，大幅增加了逻辑的不可预测性。

• 单一职责原则：SomeUseCase的核心职责应当是处理特定业务逻辑，而修改Data对象的状态属于Data类自身的职责。现在updateData直接操作Data的字段，让用例类承担了不属于它的职责，导致代码职责混乱，后续维护难度直线上升。

调试难度高的原因 #

这种写法带来的调试痛点非常明显：

• 状态变更追踪困难：当Data对象的字段值出现异常时，你需要排查所有直接引用该字段的代码，无法通过统一的入口（比如setter方法）快速定位修改来源。如果使用封装的方法修改，只需要在方法内加断点或日志就能精准追踪每一次状态变更。
• 隐式副作用难以预判：调用updateData后，传入的$data状态被悄悄修改，后续使用该对象的逻辑可能因为这个隐式变化出现意外bug，而这种问题在调试时很难第一时间关联到updateData的调用，排查成本极高。

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