设计模式初探（1）单一职责原则

2016-06-09 本文已影响399人 wuww

如果你复用代码的方式还是复制粘贴，如果你维护的模块正在变得臃肿和复杂，如果你的一次小改动会无意中引发无关模块的bug，那么你需要好好学习下设计模式了。

最近在学习中小有收获，忍不住在这里卖弄一番，同时也希望有前辈来指点一二。

谈到设计模式，首先想到的肯定是S.O.L.I.D五个设计原则。

我们可以把职责定义为“变化的原因”，单一职责就是一个类只有一个引起它变化的原因。

怎么判断一组变化是一个原因？
我试着下一个定义好了：若对每个变化A的可能a，都有且只有一个变化B的可能b与之对应，当变化a发生时b总会发生，当变化b发生时a总会发生。那么变化A和变化B是同一个变化原因。

举个例子：

模块1

模块2

模块3

模块1，模块2，模块3的功能相似。
其中的变化有：

这里有几个变化原因呢？

三角的位置和模块相对热区的位置是一个变化原因。当模块与热区左对齐时三角总是居左，当模块与热区居中对齐时三角总是居中，当模块与热区右对齐时三角总是居右。
底部文案和列表项内容当内容为收藏相关数据时，文案总为“全部收藏”；当内容为历史相关数据时，文案总为“全部历史”。
没有发生变化的部分
根据单一职责原则，没有发生变化的部分可以和任意一个变化原因放在一起。但是考虑到没有发生变化的部分在未来可能衍生出新的变化原因，所以建议将没有发生变化的部分也放在一个单独的模块中。

这样，我们就把一个复杂的功能划分成了3个简单的模块，为大脑减负（不用秃顶了~）。同时，将功能划分也是“开闭原则”的前置条件。