被问到这个问题，首先这个错误就让我很无语。不过这不是我关注的。
许多实力强劲的个人开发者都会采用MVVM+RxJava+Retrofit开发出相当精悍的个人项目。首先MVVM的databing机制省去数据更新后的回调，rxjava又是超级美，retrofit又拥有超级良好的封装。但是仅仅针对于网络框架，别这样。我以前也是这么写的，而且写过无数种类型不同的、封装地完善与不完善的网络请求。
但是这样不好。最对的，应该是ResponseModel responseModel = NetworkManager.sendRequest(RequestModel);
所有框架都成了抽象。于是项目开发只剩下了业务开发，业务逻辑和框架被剥离了。
细细想来，以前开发真的难受，做业务就做业务吧，还得写框架，写业务写到一半又被框架勾引了，嗯，这样封装不漂亮，那样封装代码太多了。如果没有一个自己的代码库，得写出洋洋洒洒的网络请求，时间都浪费光了。而且好久不写还要想老半天！
而现在。我想要发网络请求了，直接用英语说，sendRequest就搞定了。现实转抽象。
这样开发者可以只关注于业务，大大提升了开发效率。在开发中提升一倍效率肯定是有的，从框架+业务-》业务（其实光业务 就 搞死人了，需要了解系统原理debug，需要性能优化，需要理清需求快速开发，需要了解任务下的业务）。在开发之外，也无需费心费力收集代码库了，或者说可以以这种形式可以累积出一个更好的代码库。
但是框架原理又是不得不学习的。面试官总喜欢问框架源码。这一定程度上，代表了面试者的思维能力，代表了面试者的解决问题的能力，代表了面试官的学习能力也就是增量。第一个阶段是大项目的螺丝钉，无感于框架与架构，仅有感于业务逻辑。这个时候业务逻辑开发地淋漓尽致，趋于完美了，20k，30k不在话下。但是如果工资想更进一步，成为40k，50k，60k，就必须深入框架，自己为大型app写框架（大型 app的网络用tcp写的，你说理解框架重要不重要），架构整个大型系统。
回到那句代码
ResponseModel responseModel = NetworkManager.sendRequest(RequestModel);
这体现了里氏替换原则，配合接口隔离，不管是retrofit+rxjava还是okhttp、volley、tcp，随意换，无感；
也体现了迪米特原则，框架向我们暴露的东西非常至少，近乎于0
单一职责。业务逻辑、项目框架彻底剥离，各司其职。
上面代表了大厂的做法，其实可以更好，下面的写法一直是我想写成的模样
ResponseModel responseModel = ServiceManager.execute("network",“sendRequest”,RequestModel);
"network"实现了依赖注入，统一依赖ServiceManager更是减少了直接耦合，使用者只需要知道依赖ServiceManager即可，不需要知道不同的功能需要依赖哪个具体的类。
再优一点点
ResponseModel responseModel = executeService("network",“sendRequest”,RequestModel);
把ServiceManager.execute封装到类方法或者基类里去。这是一种委托模式。
到这里就完了，其实还可以更好！还有希望我自己可以尽快成为大型项目的架构者。
本文真的是硬憋出来的，不想写的，但是这几条重要的开发原则，尤其是最近深刻地也是不由自主认识到的单一职责与接口隔离原则，憋在心里很久了，正好趁着优雅的函数式代码，引出本文。