2022-09-19 单一职责

过去项目中用了日志库 orhanobut/logger: ✔️ Simple, pretty and powerful logger for android (github.com)，使用时因为它的输出策略只能用一种，要么 logcat 输出，要么 cvs 输出，并且输出全部，所以做了些扩展：

• 同时支持多种策略，并且写了个输出 txt 文件的策略，感觉比 cvs 看着方便，手机上也能直接打开
• 支持使用 Tag 过滤，在添加策略时，控制是哪些 Tag 输出日志，还是除了这些 Tag 以外的输出日志
• 有时希望将不同 Tag 的日记放到一个文件输出，这样方便看出不同日志输出的时间排序，所以支持聚合指定 Tag 的日志到一个指定的文件

做完也想说抽出一个库放到 Github 上或者 fork 一下基于源码直接改，再写个 README 说明一下详情的。但今天再看，又没心情了，没心情再去阅读源码理顺关系，因为功能已经完善能用，没那紧迫性了，就不想看了，可见这东西是有时效性的。

想起许多年前阅读《Head First 设计模式》时的惊叹不已，那本书属于精讲，没有涵盖全部的设计模式，后来不知哪年买了本《设计模式之禅》，却一直没有去看。今天开始拿出来读。

第 1 章——单一职责原则，英文 Single Responsibility Principle，我这英文水平是记不住的，或许简称 SRP 可以记住，偶尔用来装装逼。

就是说一个类只能有一个引起变化的原因，一个理论上的原则，实践上比较难。书里说接口可以这样设计，然后一个类去实现这些不同的接口，毕竟一个完整的类硬是拆成多个，属于自找麻烦。这就是兵法运用之妙，存乎一心，不可教条。

然后方法也是，要尽量功能独立，不要一个方法做好几件事，当然实践中可能有一个大的方法，然后内部定义多个小方法，譬如书中的 changeUser 要拆成 changeUserName、changeHomeAddress、changeOfficeTel 这些，如果有地方希望通过一个新用户信息去修改，每次掉这些小方法也太麻烦，还是要又个 changeUser，让它自己去调用这些细小的方法。这好像是模版方法模式?