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,觀察者核心函數(shù)func on(_ event: Event<E>)，觀察者一旦觀察到變化，立馬向外部發(fā)送信息。
RxSwift 有三個非常重要的角色，被觀察者（ObservableType），觀察者（ObserverType），以及訂閱者（Subscriber）。打個簡單的比方： A 讓C 干一件事，但是C呢只知道做事情，其他的不管，因此A不知道C事情做的怎么樣，做的好不好，所以A請B幫忙，B并不會幫C做任何事情，他只負責監(jiān)察C的工程進度，一旦有了新的進展立馬匯報給A，然后A在做相應的處理.
A :老板
C: 工人
B：監(jiān)工
三者構(gòu)成一個完整的工作體系。
那么在沒有使用RxSwift之前，這套系統(tǒng)是怎么工作的呢？

• 委托模式： A與C簽訂協(xié)議，C會按時匯報工作進度
• 觀察模式： A直接監(jiān)聽C的工作進度，根據(jù)其工作進度作出相應調(diào)整

但是不管使用哪種方式其本質(zhì)上并沒有什么區(qū)別，上述兩種模式只不過是一人分飾兩角的結(jié)果。那么使用RxSwift到底有什么優(yōu)勢呢？

想象一下場景：a把事情交給b，b又把事情交給c，那么又是什么情況呢？
如果使用委托模式，那么a與b需要簽訂協(xié)議,b與c同樣需要簽訂協(xié)議
如果使用觀察模式呢，那么a需要監(jiān)聽b,b監(jiān)聽c
顯然隨著中間層數(shù)越來越越多，代碼變得越來越復雜臃腫，越來越艱澀難懂，維護起來越來越難。其具體表現(xiàn)在于

• 核心代碼分散在不同的類中，無法體現(xiàn)其整體性
• 不利于理解，需要逐層追蹤代碼，才能真正理解其意義
• 這些代碼都內(nèi)嵌在各自類中

綜上所述我們需要的是什么呢？

• 簡潔性 不會隨著中間層數(shù)的增加，增加額外的不必要的代碼
• 可讀性 不會隨著中間層數(shù)的增加，增加閱讀難度，讓人一目了然，保持代碼的清晰性
• 獨立性 無須改變對象的類部結(jié)構(gòu)

RxSwift解決的就是這個，通過設(shè)計ObservableType，ObserverType核心協(xié)議，讓這種概念更加更加清晰，一旦某個類同時支持ObservableType，ObserverType協(xié)議那么，就可以做拼接，就像一個水管，要把多個水管拼接起來，必須要在水管連接處添加套筒，而同時支持這兩個協(xié)議的類就相當于自帶套筒的水管，可以自由拼接其他水管，是那么的自然，輕松。