这篇文章非常生动的解释了一个原则：SRP单一自责原则。SRP是SOLID五大设计原则中最容易被误解的一个。也许是名字的原因，很多程序员根据SRP这个名字想当然地认为这个原则就是指：每个模块都应该只做一件事。我们在将大型函数重构成小函数时经常会用到这个原则，但这只是一个面向底层实现细节的设计原则，并不是SRP的全部。
正文：你给我解释清楚，都有了CALayer了，为什么还要UIView？
UIView继承自UIResponder，主要特点是可以响应触摸事件。而CALayer实际是图层内容管理。大家干的的事情不一样，是两个东西，大家的存在互不影响，理所当然。
但仔细想想，真的是步步高点读机，So Easy吗？在细细揣摩背后的用意的时候，就会发现OMG！！！
UILayer
假如UIKit不是出自苹果之手，而是来自于我们，可能会出现什么情况呢？是的，可能UIView就和CALayer合体成了一个叫“UILayer”的东西了。这个UILayer是一个全能的Layer，可以负责管理显示内容，也能处理触摸事件，吊吊的，对不对！
好的！假设UILayer老早就这么腻害了，在iOS2就存在了，真机智，一开始就设计的这么腻害了。
现在，你的产品经理过来，还带着微笑。在iOS3.2版本要加上手势识别。这好办，改一下UILayer的加一个手势识别就好了。
你的产品经理又过来了，还拍你肩膀了，多么信任你，是不是。既然在iOS4引入了Block语法，把之前的动画增加一个Block的版本吧。你想了想，容易，改一改UILayer的源码就好。
你的产品经理又过来了，诶哟，还带了两枚产品妹子过来了，把你围住了，都是公司红人啦，众望所托，有点害羞哦。
这次叫你在iOS6增加一个叫做AutoLayout的Big Feature哦。这真的是一个很大的功能，要改很多地方，给测试也带来很多困难，现在UILayer这个类已经越来越大，功能强大得如同要你命3000了，发布不能延期，这又是这么重要的一个类，还要对得起那妹子对你含情脉脉的期待，得小心翼翼的改了。最终你还是搞定了，哈哈，年终的优秀员工就是你啦。
你的产品经理又过来了，哟哟，搂你脖子，给你讲笑话，还要请你吃饭咧，哦，产品妹子还在后面老在夸你呢。是的，又一次来到历史性时刻，iOS迎来了改头换面的第七个大版本。
iOS7变得小清新了，还有加入物理效果哦，甚至视差都有，产品经理是要颠覆产品设计理念，试图再一次改变世界哦，甚是了不得呀。然后，你点开那巨长的UILayer类，看来是要从头改到脚了，但是要改那么多东西，时间有限啊，改完测试的时间貌似也不够啊，怎么办，重构更是不可能了，一年一度的发布是不能延期的，不然公司怎么在全世界面前挂住面子。可是时间就是这么不等人，就算天天程序员鼓励师鼓励也救不了你，你控制不了的代码了，在iOS7这个历史关口，你的神话倒下了。
分析
所以，在这份理所当然的SDK的背后，蕴藏着大牛门几十年的设计智慧。当中应该能够看到很多门道。这次就UIView和CALayer来分析，就可以得出一些东西。
-
机制与策略分离
-
更多的不可变
-
各司其职
-
漏的更少
1. 机制与策略分离
Unix内核设计的一个主要思想是——提供(Mechanism)机制而不是策略(Policy)。编程问题都可以抽离出机制和策略部分。机制一旦实现，就会很少更改，但策略会经常得到优化。例如原子可以看做是机制，而各种原子的组成就是一种策略。CALayer也可以看做是一种机制，提供图层绘制，你们可以翻开CALayer的头文件看看，基本上是没怎么变过的，而UIView可以看做是策略，变动很多。越是底层，越是机制，越是机制就越是稳定。机制与策略分离，可以使得需要修改的代码更少，特别是底层代码，这样可以提高系统的稳定性。
2. 更多的不可变
稳定给你的是什么感觉？坚固？不可形变？稳定其实就是不可变。一个系统不可变的东西越多，越是稳定。所以机制恰是满足这个不可变的因素的。构建一个系统有一个指导思想就是尽量抽取不可变的东西和可变的东西分离。水是成不了万丈高楼的，坚固的混凝土才可以。更少的修改，意味着更少的bug的几率。
3. 各司其职
即使能力再强也不能把所有事情都干了，万一哪一天不行了呢，那就是突然什么都不能干了。所以仅仅是基于分散风险原则也不应该出现全能类。各司其职，相互合作，把可控粒度降到最低，这样也可以是系统更稳定，更易修改。
4. 漏的更少
接口应该面向大众的，按照八二原则，其实20%的接口就可以满足80%的需求，剩下的80%应该隐藏在背后。因为漏的少总是安全的，不是吗？剩下的80%专家接口可以隐藏于深层次。比如UIView遮蔽了大部分的CALayer接口，抽取构造出更易用的frame和动画实现，这样上手更容易。
总结
以前或多或少的了解过或者听过单一自责原则。哪怕现在专门去看了文章，去查询了资料，去了解了这个原则，但是在实际的开发过程中，不一定能去使用这个原则。或者，我们换一个开发语言，比如：Python，我们能从 Python 的一些库中体会到这种设计原则吗？也许也很难。原因是我们缺一种东西：思考。我们会用工具，但是不一定会设计工具。底层的机制才是最核心的！
欢迎关注【无量测试之道】公众号，回复【领取资源】
Python编程学习资源干货、
Python+Appium框架APP的UI自动化、
Python+Selenium框架Web的UI自动化、
Python+Unittest框架API自动化、
资源和代码 免费送啦~
文章下方有公众号二维码，可直接微信扫一扫关注即可。
备注：我的个人公众号已正式开通，致力于测试技术的分享，包含：大数据测试、功能测试，测试开发，API接口自动化、测试运维、UI自动化测试等，微信搜索公众号：“无量测试之道”，或扫描下方二维码：
添加关注，让我们一起共同成长！