单一原则

在软件开发领域，提到单一原则，一般的解读是“一个类只有一个职责”。
这里我不准备对这一解读进行展开，而是针对“单一原则”本身进行展开解读。

一个变量

一个变量数据应该只有一个用途，中途不要改变用途，及时之前的用途已经结束了。在想改变用途的时候，增加一个变量吧，并不会占用多少内存，更何况现代的编译器、cpu已经足够强大，能够在编译或运行时进行自动优化。

一切以优化为借口所做的违背编程基础原理的事情都是耍流氓。优化前请做好调研，拿到优化前后的数据指标，才能判断所做的优化是否值得。

一个方法

一个方法应该只做一件事情。

方法的命名

方法名称就是这一事件的总结表述。一般的方法命名规则应该是“一个动词+一个可选的名词”。如果在对一个方法起名字的时候，发现名字超长或者中间需要and、or等词语进行连接，就要先考虑一下这个方法的内容是不是太多了。

可能会有人拿compareAndSet这个方法来怼我。是的，两个动词中间还有一个and，完全违背了上面说的原则，但是他是有非如此不可的理由的。而我们平常开发的代码，99.9%都没有这样充足的理由让我们用两个动词去描述一个方法。

方法的输入与输出

方法的输入要尽量在入参中表达，如无必要，不要在其他地方获取。
方法的输出要在返回值或回调接口中体现，不应该以其他形式提供给调用者。

Android中，启动Activity并获取其返回值(onActivityResult或onRequestPermissionsResult)就是一个反例。这样的设计肯定是有他的原因的，但是仍然可以看到这样的设计造成的一些难以理解、无法解耦的客户端代码设计。

一个提交(commit)

作为开发者，提交(commit)这个概念应该都不陌生，没接触过的可以了解一下git等版本管理工具，这里不做介绍。

这里要强调的是，一次提交，也要遵循单一原则。

那一个提交怎么才能叫单一呢？ 能一句话表述的，就叫单一。提交代码时一定要写好提交信息(Commit Message)，这东西比注释更有用，注释还可能会因为代码变化而出错，但是提交信息是和代码绑定的，不会有这种问题，后人很容易查找相关信息。好的提交信息可能会包含：功能描述、背景信息、解决的问题、参考资料、相关链接等不一而足。

同样的，在描述提交信息时，如果描述信息出现了两段毫不相干的语句，建议拆成两次进行提交，当然无法拆分的除外。

所以一个单一的提交，并不以其内容的多少而定义，他可以是整个新开发的功能，也可以是简单的一个字符改动。

一个类

单一原则的原始定义就是从“一个类”触发的，这里不过多介绍了。网上搜一搜，会得到更多更专业的解读。

一个模块

一个模块，体现为Android Studio中的module或library等。

一个单一的模块，其功能需要有一个共同的主题，解决一个或一系列相关的问题。

一个应用

一个应用，要保持自己的单一性，从一个中心出发，为用户提供相关联的功用。

抵挡住流行的诱惑，避免什么火就接什么功能，避免别人有什么就做什么功能。不忘初心，方得始终。

牢记奥卡姆剃刀原则：如无必要，勿增实体。

一个设备

写到这里，有些跑题了，我的主题是软件开发啊~~ 说单一原则的文章没有做到单一性，什么鬼啊~~

不过还是忍不住加上这一小节，算是举一反三的思考吧，也可以看成是生活中的小提示。

一个设备，或任意实物，也要保持其单一性。但凡遇到“多功能”这个词的时候，都要多个心眼避免入坑。

台灯，很常见的家电。可充电的台灯，嗯可以离开电源了，好东西。可充电可播放音乐的台灯，嗯~ 什么鬼？

听说有一款能播放音乐的加湿器。我只能说，这波操作好骚啊~~

并不是说功能越多越不好，而是要分辨这组合在一起的多个功能有没有组合在一起的必要。比如上面的MP3+加湿器，开发者是想在路上抱着加湿器边加湿边听音乐吗？

写在最后

总之，如果一个实体可以“用一句话描述清楚明白”，那我们就可以说这个实体是符合“单一原则”的。