Angular共享服务将属性设为私有搭配getter/setter的原因

• 从根源上避免共享流被意外破坏
  把someValue$声明为私有属性后，这个数据流的生命周期控制权完全收归服务内部：只有服务自己能决定要不要终止流（调用complete()/error()）、要不要替换流的实例引用。如果直接把Subject设为public对外暴露，任何引入了这个服务的组件都能随意把流掐断，甚至直接给这个属性重新赋值一个全新的Subject，导致之前所有订阅了旧流的组件再也收不到数据更新，这类隐蔽的误操作问题排查起来非常耗时。而对外暴露的setter只开放了next()推送新值的最小权限，从设计上堵死了这类误操作的可能。
• 降低后续迭代的维护成本
  所有对这个状态的读写都走统一的方法入口，后续如果要加值校验、日志埋点、防抖节流、赋值联动其他逻辑，只需要修改服务内部的getter/setter代码即可，所有已经在调用这些方法的业务组件完全不需要改动。如果直接把属性暴露出去，外部代码到处都是直接操作属性的写法，后续要加通用逻辑就得逐个找所有调用点修改，很容易漏改出线上问题。
• 屏蔽内部实现细节，保留迭代灵活性
  对于使用服务的组件来说，它只需要知道“可以拿到状态流、可以更新状态值”就够了，根本不需要关心服务内部到底用的是BehaviorSubject、ReplaySubject还是普通Subject，也不需要知道内部有没有做缓存、值转换。通过方法暴露访问入口的话，后续哪怕要把内部的流实现换成其他类型，或者调整getter的返回逻辑（比如常见的改造成返回asObservable()的只读流，彻底禁止外部操作Subject本体），对外的调用方式都不会变，不会产生破坏性的代码变更。
• 明确团队协作的使用边界
  TypeScript的private修饰符虽然只是编译时的类型检查，运行时不会做强制拦截，但它相当于给所有协作的开发者一个明确的契约提示：这是服务的内部状态，不要直接操作，否则产生的非预期问题不在兼容范围内。能很大程度上减少开发时图省事乱改内部状态的野路子写法，降低代码腐化的速度。

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