设计模式：算法封装（模板方法，策略）

六、算法封装

17、模板方法：定义一个操作中算法的骨架，而将些步骤延迟到子类中。模板方法使子类可以重定义算法的某些特定步骤而不改变该算法的结构。

 

模板方法会调用5种类型的操作：

（1）  对具体类或客户端类的具体操作

（2）  对抽象类的具体操作

（3）  抽象操作

（4）  工厂方法

（5）  钩子操作

 

18、策略模式： 定 义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。 也称为 政策模式 (Policy) 。

当存在以下情况时使用Strategy模式

1）• 许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。

2）• 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。

3）• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。

4）• 一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

案例：

例如，我们在验证用户输入的表单的时候，加入包括电话输入框的验证和邮件输入框的验证，这两部分的验证算法是不同的，如果把这个算法看成一个函数，他几乎有相同的输入参数和返回参数。

我们可以把这个相同的函数可以抽象为基类(InputValidator)的一个方法(bool validateInput(input,error))，然后抽象出两个具体的策略类：电话验证类(PhoneValidator)和邮件验证类(EmailValidator)，他们需要在各自的实现里面去复写父类的验证方法。

为了能够正常的调用到验证类的验证方法，我们需要自定义一个UITextField的子类CustomTextField，其中有一个InputValidator类型的引用和一个validate方法，该方法里面调用InputValidator的验证方法，然后在textFieldDidEndEditing代理方法里面调用CustomTextField的validate方法，这样就不用我们在判断输入是否合法的时候通过if else去处理每种逻辑，而且这样做方便扩展，提高可复用性。 

19、命令模式（250）：将请求封装成一个对象，从而可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。