单一职责

仅作个人记录

最近封装了一个项目的Toolbar，在开发中有着各种各样的收获，比如对建造者的意义的深入理解，对Toolbar源码的阅读与Toolbar布局规则的改善。。。其中的一点收获是单一职责。

我封装了一层Toolbar的原生样式改善层，一层自定义View添加层，其功能拆分得可谓完美，在无数次划分职责的思考中最终选择了这样的划分，真的很棒。

第一层，职责是Toolbar的原生样式，他的NavigationIcon、Title字体都是我需要的，可是受到的限制很大，我就通过某些手段，突破了这些限制，可以说这一层封装后，Toolbar依然是Toolbar，但是他的样式更灵活了，比如Title可以居中了，右边也有了一模一样的ImageButton。可以说相当于官方的修改了，等同于官方修复了他样式不够灵活的bug。

第二层，在更多的位置上可以插入View，算是自定义View层。

这样划分的好处在于，第一层等同于bug修复，好像官方修复了不足之处一样。我现在做的才是真正的Toolbar封装。这是运气好，第一层功能被吞并了，使得这次开发太舒服了。

不过就算我是封装的2层，也是很舒服了。这样维护起来，别人阅读起来，使用者使用起来，都很舒服，因为每一层都对应一个功能，我如果写在一起，或者分层不明确，日后修改，头都要大了。现在好了，改动非常有目标性，非常清晰。

单一职责

难道我会谈事件分发、OkHttp和网络分层的责任链模式来述说单一职责？当然不是。这些已经算是很抽象了，离真正开发似乎很远。近一点，MVP难道不是单一职责吗？数据层，组织层，UI层，这样一分，简直美到心醉。以后维护起来是一种享受！！（当然了，MVP还用了接口隔离的思想）