javascript - asObservable 主题的缺点

Question

您好，我真的很质疑对主题调用“asObserveable()”的用法。

在我看来，它会产生大量不必要的开销。 在我看来，阻止调用“next()”或“complete()”是没有用的。

你能给我一个你应该这样做的好理由吗？

比较一下这两个

1. 没有

export class TestService {
     public get test$(): Observable<test> {
        return this.test$.asObservable();
     }
    
      public get test2$(): Observable<test> {
        return this.test2$.asObservable();
      }
    
      public get test3$(): Observable<test3> {
        return this.test3$.asObservable();
      }
    
      public get test4$(): Observable<test4> {
        return this.test4$.asObservable();
      }
    
      private readonly _test1$ = new ReplaySubject<test1>(1);
      private readonly _test2$ = new ReplaySubject<test2>(1);
      private readonly _test3$ = new ReplaySubject<test3>(1);
      private readonly _test4$ = new ReplaySubject<test4>(1);
 }

1. 没有

 export class TestService {  
      public readonly test1$ = new ReplaySubject<test1>(1);
      public readonly test2$ = new ReplaySubject<test2>(1);
      public readonly test3$ = new ReplaySubject<test3>(1);
      public readonly test4$ = new ReplaySubject<test4>(1);
}

Answer 1

subject 的 asObservable 缺点

一些样板代码。别的不说了。

In my view it creates a big unnecessary overhead.

你测过吗？ Subjects 扩展了 Observables，它所做的只是创建一个浅拷贝。如果您发现差异大于方差(实际上不可测量)的应用，我会感到惊讶。

主题 asObservable 的优点

更简洁的架构意味着更容易找到错误和/或更容易从一开始就阻止错误的产生。

封装是干净架构的基础之一。因为封装从其他部分隐藏了我们程序的某些部分，所以它使每个部分更容易推理。因此更易于理解、编写、扩展和维护。

如果架构良好的系统中存在错误，表面积会小得多。

一般来说，这类决策的好处往往会在拥有更大团队的大型项目中体现出来。如果您正在家里编写一个业余爱好项目，或者您自己或一个小团队正在制作一个最小可行的产品，那么放弃过度计划以加快速度可能是有意义的。这样的项目一旦发展壮大，可能需要重新编写/大修，但到那时，额外的努力将是值得的。

Subject 的 asObservable 的替代方案

如果您有相对严格设置的静态类型检查器(TypeScript、Elm、PureScript、ClojureScript 等)，那么您可以将 Subject 作为 Observable 返回，而无需对该类型的运行时表示进行任何更改。

您获得了零运行时成本的封装。