这篇文章不是讲解rxjava如何使用，而是对其设计的思考。
使用过rxjava的同学们都注意到rxjava的操作符很多很多，具体有多少？
对于这么多的操作符，如果作为大多数的我们而言，由我们来设计，当然是针对不同的操作符实现自己的逻辑即可咯。但是实际情况当然不是这么简单，rx操作符只要不是最终执行subscribe订阅，操作符是可以无限制切换调用的，例如.just(...).map(...).filter(...).take(...).map(...)，只要你想调，你就可以一直调下去。
问题1：为什么要设计成操作符可以无限切换？
这个其实不难理解，基本就是为了达到业务处理的灵活性。
试想一下，如果操作符间不能随意切换，做完一件事就结束了，那我们为什么要多此一举要用rxjava，还不如我们不用，完全可以直接写业务代码的嘛。
所以，这里就引出了rxjava的事件流的概念，每调用的一个操作符都是事件流的一部分，从上流可以一直流到下流直到结束，或者中途异常中断或跳过处理等等。这就好比使用app买门票一样，会有个注册 -> 登录 -> 买门票的流程，流程一切正常，ok，门票购买成功，否则就是不成功。
对于该种设计的优点，我个人认为主要有以下几点：
a、对于多种业务地狱式回调，使用rx则可以免去这些回调，使用官方的语言就是响应式编程。其好处就是代码更加直观，减少维护成本；
b、更灵活的业务处理。
这点很重要，例如由于版本迭代，某个版本突然产品经理要加某个功能点，但随着代码设计复杂度的提升，改动特别麻烦。但是rxjava的方式，或许就是再额外加个操作符的事情，其不仅仅是增加方便，删除也很方面，或许就是删除指定操作符调用而已。c、解耦不同业务间的耦合。
从上班的那天起，耦合便无时无刻不伴随我们身边。优秀的代码，不少都是耦合度很低的代码。为什么很多时候我们都不愿意看别人的代码？不仅仅是编码习惯的不同，耦合的问题也是我们不愿看别人代码的一部分原因，谁都不愿意看到所有业务糅合在一块的垃圾代码吧。
但是我们该如何通过rxjava解耦？当然也是可以从操作符上边下功夫了。具体业务只做一件事情，对应一个操作符，尽量做到细粒度(当然了，有时候还要具体情况具体对待)。
问题2：如何做到操作符的无限切换？
试想一下，如果是由我们自己去设计一套类似rxjava操作符，我们该如何实现呢？
是不是要在每个操作符内部还要判断当前操作符之前是否加入过其他操作符，如果加入过，还要处理其他操作符的逻辑？
如果随着业务的不断增长，又要加入其他操作符，难道我们每次都要改动所有操作符内部实现？
以上两种处理方式当然是不切合实际的？当你已走上这种道路，其实你开始就已经给自己今后挖坑了，而且这种坑是会无限制的放大，懂了吧。
也就是说上面的方式是通过强耦合的方式实现的，既然如此，如何免去耦合，还能灵活的完成各操作符自有逻辑？
有人可能会想，又想实现现有功能，又不想影响其他功能，哪有这种好事啊？实话告诉你，还真的有，而且必然有，这些思想都是前人走过来并且总结的经验。这些经验大多都在设计模式之中有所体现，这也正是设计模式魅力的体现，但也不能因模式而模式。
现在转变下思路，如果将每个操作符都想象成一种咖啡，现有浓缩咖啡，玛琪雅朵，美式咖啡，白咖啡，拿铁咖啡，并且假如每种咖啡都可以随意组合，以符合不同人的口味，无论哪种咖啡，它都是咖啡，当把他们随意组合之后，难道他们就不再是咖啡了吗，当然还是。无论你想喝哪种组合的咖啡，我当然不会蠢到每次都一个一个的定制，因为有现成的咖啡，组合一下就可以了嘛。大家想到了吗？这正是装饰模式。
装饰模式实在是太强大了，实在是无法说其到底有多好，哈哈。无论你产品经理如何提需求，在整体逻辑类似的情况下，我就只需要再掏出一个指定逻辑的装饰器即可。rxjava也正是用到了这种思想，每当你切换一个操作符，其实对他而言也就只不过是在前一个装饰器基础上再额外添加当前一个装饰器而已，在发布订阅后，当前装饰器执行完毕后，再让上一个装饰器去执行其自己逻辑，以此类推。
下边以一个简单的字符串小写转大写，并配合其具体流程图+类图来加深对rxjava的印象：
fun doWithMap() {
Observable
.create {
it.onNext("abc")
}
.map {
it.toUpperCase(Locale.ROOT)
}
.subscribe {
L.e(it)
}
}
该实现对应的大致rx执行流程图为：
以ObservableCreate为例的类图(由于Observable系列的装饰类实现大同小异，故单以其中的ObservableCreate为例）：