单一职责
开闭原则
里氏替换原则
依赖倒置原则
接口隔离原则
迪米特原则
单一职责就是拆分功能片，至于这个功能片怎么定义的，看你需求和经验
开闭原则就不多说了，我们写东西写出来后的最基本的要求就是开闭原则
里氏替换原则，比如NetworkManager.sendRequest(Request)，这个sendRequest随意用什么框架都行，这种开发模式就从具体世界到达了抽象世界，这也是面向对象的意义——让你的代码，变成语言文字一样简单。比如我这里的发送网络请求，翻译过来不就是sendRequest？NetworkManager.sendRequest整个翻译过来不就是，我找网络中心，帮我发个网络请求？这样一来，开发甚至可以用伪代码，可以用文字，开发也变成了两个步骤，1.我说出来，要干什么2.再去实现这个干什么。其实实现不实现都不急了，用谁实现也无所谓了，如果懒得写，网上找个开源框架也行。
依赖倒置原则，其实就是面向接口编程。和上面的里氏替换原则类似，接口就是抽象，是行为的表达，我要请求网络，就NetworkManager.sendRequest，这应该是最优的模块交互方式。
接口隔离，比如WindowManager，为什么还要有一个WindowManagerImpl呢？明明WindowManager没有多个实现啊？这就是接口隔离，你写一个框架，肯定是暴露接口给别人用，暴露类，等于暴露了多余的API与实现细节。
迪米特原则，还是NetworkManager.sendRequest举例。平时网络请求要写Request类，写RequestBody，写OkHttpBuilder，Call等等，其实这些都和我无关的，你又何必让我来增加这没必要的工作量呢？我只是要网络请求，为何要学你的框架呢？那我不是和你的框架直接耦合了吗？迪米特原则倡导的就是知道的越少越好，我发送网络请求，我直接找一个NetworkManager代理让他发好了，何必还要做那么多一系列复杂的工作？
最后对单一职责进一步说明
有些开发者会分的很极端，把属性都会单独放在一个类里管理。由此我联想到，做拆分不是不行，但是做了拆分后，请在项目里增加一个txt文本来说明，描述这个框架的树状关系，否则有时候大量的拆分，配合令人难以理解的命名，会让阅读者花费不少时间去理解。