设计模式学习笔记

行为模式

策略模式

该模式将解决问题所用到的算法独立出来，抽象成一个类
当一个问题有很多种 算法，或者希望用多种算法适配的解决问题，可以考虑此设计模式

策略模式结构

• 上下文 （Context） 维护指向具体策略的引用， 且仅通过策略接口与该对象进行交流。
• 策略 （Strategy） 接口是所有具体策略的通用接口， 它声明了一个上下文用于执行策略的方法。
• 具体策略 （Concrete Strategies） 实现了上下文所用算法的各种不同变体。
• 客户端 （Client） 会创建一个特定策略对象并将其传递给上下文。 上下文则会提供一个设置器以便客户端在运行时替换相关联的策略。
  当上下文需要运行算法时， 它会在其已连接的策略对象上调用执行方法。 上下文不清楚其所涉及的策略类型与算法的执行方式。

优点

• 将算法与数据分离，改变算法仅需要修改算法部分的逻辑

迭代器模式

实现一个迭代器来进行容器中数据的访问

迭代器模式结构

• 迭代器 （Iterator） 接口声明了遍历集合所需的操作： 获取下一个元素、 获取当前位置和重新开始迭代等。
• 具体迭代器 （Concrete Iterators） 实现遍历集合的一种特定算法。 迭代器对象必须跟踪自身遍历的进度。 这使得多个迭代器可以相互独立地遍历同一集合。
• 集合 （Collection） 接口声明一个或多个方法来获取与集合兼容的迭代器。 请注意， 返回方法的类型必须被声明为迭代器接口， 因此具体集合可以返回各种不同种类的迭代器。
• 具体集合 （Concrete Collections） 会在客户端请求迭代器时返回一个特定的具体迭代器类实体。 你可能会琢磨， 剩下的集合代码在什么地方呢？ 不用担心， 它也会在同一个类中。 只是这些细节对于实际模式来说并不重要， 所以我们将其省略了而已。
• 客户端 （Client） 通过集合和迭代器的接口与两者进行交互。 这样一来客户端无需与具体类进行耦合， 允许同一客户端代码使用各种不同的集合和迭代器。

客户端通常不会自行创建迭代器， 而是会从集合中获取。 但在特定情况下， 客户端可以直接创建一个迭代器 （例如当客户端需要自定义特殊迭代器时）。

优点

• 隐藏容器背后的复杂数据结构
• 减少重复遍历代码
• 一个迭代器可以适配多个数据结构