分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net
装饰器，适配器和代理我觉得可以不用分得那么清，都是为了使现有的类的行为满足我们新的需求而做的一层封装。最经典的例子就是Java I/O中的高级流，低级流了。那么在UI自动化中会有什么情况会用到呢？最常用的就是重试的功能。UI自动化是出了名的不稳定的，有很多公司都会启用失败重跑的功能。逻辑很暴力，当Case运行失败的时候就重跑整个Case。这种暴力的做法优缺点很分明。
优点：
- 实现简单，一些测试框架比如TestNG已经支持这种功能
缺点：
- 失败的Case也会进入Report中，要对Report做单独处理
- 只要失败就重跑的策略会在很多时候大大的增加了测试的执行时间。比如本来就是Bug引起的失败还是去重新运行的话，最终还是会失败的，白白的浪费了执行的时间和资源。尤其是在有很多长时间的异步任务的产品中，这种策略更加无法忍受
鉴于上面所说的缺点，我们希望可以有重试的功能，但还希望能够控制重试的执行粒度。比如运行时间短的，成本较低的，容易出错的，UI操作复杂的是可以重试的；但是那些运行时间长的，不容易出错的非UI任务我们是不重跑的。我们也并不希望把失败重跑的功能加到原有类里面，一来是因为我们要遵循设计原则，只让一个类负责尽量少的事情。二来是有些情况下，我们也希望没有失败重跑的功能，直接将异常抛出来，由调用方处理。 所以我们使用装饰器模式，封装一个装饰器类。要点如下：
- 装饰器类可以实现被装饰的类的接口，保持接口兼容和使用方式一致
- 装饰器类在创建时传递被装饰的对象，然后在方法中调用被装饰对象的方法，并添加自己的新功能，也就是失败重跑
PS：有时一些简单稳定的操作会超时，这时候重试是有可能会让这些操作跑过去，但是我们是不会这么做的。因为环境本身就出现了问题，这里我们是希望Case就这么直接失败的，减少不必要的运行时间。所谓失败了也要快速的失败，快速的反馈。