RxSwift到底解决什么问题

ObserverType

public protocol ObserverType {
    /// The type of elements in sequence that observer can observe.
    associatedtype E

    /// Notify observer about sequence event.
    ///
    /// - parameter event: Event that occurred.
    func on(_ event: Event<E>)
}

/// Convenience API extensions to provide alternate next, error, completed events
extension ObserverType {
    
    /// Convenience method equivalent to `on(.next(element: E))`
    ///
    /// - parameter element: Next element to send to observer(s)
    public func onNext(_ element: E) {
        on(.next(element))
    }
    
    /// Convenience method equivalent to `on(.completed)`
    public func onCompleted() {
        on(.completed)
    }
    
    /// Convenience method equivalent to `on(.error(Swift.Error))`
    /// - parameter error: Swift.Error to send to observer(s)
    public func onError(_ error: Swift.Error) {
        on(.error(error))
    }
}

ObserverType,观察者核心函数func on(_ event: Event<E>)，观察者一旦观察到变化，立马向外部发送信息。
RxSwift 有三个非常重要的角色，被观察者（ObservableType），观察者（ObserverType），以及订阅者（Subscriber）。打个简单的比方： A 让C 干一件事，但是C呢只知道做事情，其他的不管，因此A不知道C事情做的怎么样，做的好不好，所以A请B帮忙，B并不会帮C做任何事情，他只负责监察C的工程进度，一旦有了新的进展立马汇报给A，然后A在做相应的处理.
A :老板
C: 工人
B：监工
三者构成一个完整的工作体系。
那么在没有使用RxSwift之前，这套系统是怎么工作的呢？

• 委托模式： A与C签订协议，C会按时汇报工作进度
• 观察模式： A直接监听C的工作进度，根据其工作进度作出相应调整

但是不管使用哪种方式其本质上并没有什么区别，上述两种模式只不过是一人分饰两角的结果。那么使用RxSwift到底有什么优势呢？

想象一下场景：a把事情交给b，b又把事情交给c，那么又是什么情况呢？
如果使用委托模式，那么a与b需要签订协议,b与c同样需要签订协议
如果使用观察模式呢，那么a需要监听b,b监听c
显然随着中间层数越来越越多，代码变得越来越复杂臃肿，越来越艰涩难懂，维护起来越来越难。其具体表现在于

• 核心代码分散在不同的类中，无法体现其整体性
• 不利于理解，需要逐层追踪代码，才能真正理解其意义
• 这些代码都内嵌在各自类中

综上所述我们需要的是什么呢？

• 简洁性 不会随着中间层数的增加，增加额外的不必要的代码
• 可读性 不会随着中间层数的增加，增加阅读难度，让人一目了然，保持代码的清晰性
• 独立性 无须改变对象的类部结构

RxSwift解决的就是这个，通过设计ObservableType，ObserverType核心协议，让这种概念更加更加清晰，一旦某个类同时支持ObservableType，ObserverType协议那么，就可以做拼接，就像一个水管，要把多个水管拼接起来，必须要在水管连接处添加套筒，而同时支持这两个协议的类就相当于自带套筒的水管，可以自由拼接其他水管，是那么的自然，轻松。