单个类可同时实现IObserver和IObservable接口吗？此做法是否为不良实践？

1. 单个类能否同时实现IObserver与IObservable接口？ #

完全可以。从语法规范和设计逻辑层面，没有任何规则禁止这种实现方式。只要你的类在业务场景中既需要对外发布事件（承担Observable角色），又需要订阅其他对象的事件（承担Observer角色），同时实现两个接口是完全合理的选择。

比如在消息中转系统里，某个组件需要接收上游节点的消息（作为Observer），处理完成后再将结果推送给下游节点（作为Observable），这种场景下同时实现两个接口是自然的职责组合。

2. Observable类是否可同时作为Observer？ #

答案是肯定的。Observable的核心能力是维护观察者列表并触发事件通知，Observer的核心是实现事件接收后的更新逻辑，这两个角色的职责并不冲突。一个类完全可以同时承担这两种角色，只要业务逻辑需要这种双向交互的能力。

3. 这种使用方式是否可行，是否属于不良实践？ #

可行性毋庸置疑，但是否属于不良实践需结合场景判断： #

• 合理场景：
  • 事件中转/处理节点：比如数据管道中的格式转换器，接收原始数据后转换格式再转发，同时作为Observer和Observable是职责的自然延伸。
  • 状态联动组件：比如一个协同工作的UI控件，既要监听其他控件的状态变化（Observer），自身状态改变时又要通知依赖它的其他组件（Observable）。
• 需警惕的不良场景：
  • 职责过度耦合：如果一个类同时实现两个接口，但发布和订阅的逻辑完全无关，只是强行将不相关的职责塞进同一类中，会导致类的职责模糊，违反单一职责原则。
  • 循环依赖风险：若A订阅了B的事件，同时B也订阅了A的事件，可能触发循环通知，导致无限递归或消息风暴，这种情况需要额外添加循环检测逻辑来规避。

总结来说，这种实现方式本身并非不良实践，关键在于是否符合单一职责原则以及是否有明确的业务逻辑支撑。只要职责清晰、逻辑自洽，同时实现两个接口是完全可行的设计选择。

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