设计模式——迭代器设计模式（行为型）

摘要

本文详细介绍了迭代器设计模式，这是一种行为型设计模式，用于顺序访问集合对象中的元素，同时隐藏集合的内部结构。文章首先定义了迭代器设计模式并阐述了其核心角色，包括迭代器接口、具体迭代器、容器接口和具体容器。接着，文章通过 Java 标准库中的 Iterator 接口为例，展示了迭代器设计模式的结构和实现方式。此外，文章还探讨了迭代器设计模式的适用场景，包括适合和不适合使用该模式的情况，并通过金融风控的实战示例，展示了如何将迭代器设计模式与其他设计模式（如责任链模式、策略模式等）结合使用。最后，文章总结了迭代器设计模式与其他设计模式的组合使用方式。

1. 迭代器设计模式定义

迭代器设计模式（Iterator Pattern）是一种行为型设计模式，用于顺序访问一个集合对象中的元素，而又不暴露该对象的内部表示结构。

1.1. 🔹 核心角色：

Java 标准库中广泛使用了该模式，例如 java.util.Iterator 接口就是该模式的典型实现。

List<String> list = new ArrayList<>();
list.add("A");
list.add("B");
Iterator<String> iterator = list.iterator();
while (iterator.hasNext()) {
    System.out.println(iterator.next());
}

2. 迭代器设计模式结构

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

2.1. 迭代器类图

2.2. 迭代器时序图

3. 迭代器设计模式实现方式

迭代器设计模式的实现方式主要包括自定义以下四个关键角色：容器接口、具体容器、迭代器接口、具体迭代器。下面是标准的实现步骤（以 Java 为例）。

3.1. 🔹 定义迭代器接口 Iterator

public interface Iterator<T> {
    boolean hasNext();
    T next();
}

3.2. 🔹 定义聚合容器接口 Aggregate

public interface Aggregate<T> {
    Iterator<T> createIterator();
}

3.3. 🔹 实现具体容器 ConcreteAggregate

public class ConcreteAggregate<T> implements Aggregate<T> {
    private List<T> items = new ArrayList<>();

    public void add(T item) {
        items.add(item);
    }

    public T get(int index) {
        return items.get(index);
    }

    public int size() {
        return items.size();
    }

    @Override
    public Iterator<T> createIterator() {
        return new ConcreteIterator<>(this);
    }
}

3.4. 🔹 实现具体迭代器 ConcreteIterator

public class ConcreteIterator<T> implements Iterator<T> {
    private ConcreteAggregate<T> aggregate;
    private int currentIndex = 0;

    public ConcreteIterator(ConcreteAggregate<T> aggregate) {
        this.aggregate = aggregate;
    }

    @Override
    public boolean hasNext() {
        return currentIndex < aggregate.size();
    }

    @Override
    public T next() {
        return aggregate.get(currentIndex++);
    }
}

3.5. 🔹 使用示例

public class Main {
    public static void main(String[] args) {
        ConcreteAggregate<String> container = new ConcreteAggregate<>();
        container.add("A");
        container.add("B");
        container.add("C");

        Iterator<String> iterator = container.createIterator();
        while (iterator.hasNext()) {
            System.out.println(iterator.next());
        }
    }
}

3.6. ✅ 迭代器示例总结

4. 迭代器设计模式适合场景

迭代器设计模式的核心目的是提供统一的遍历接口，屏蔽容器内部的数据结构差异。下面是它适合与不适合的场景分析：

4.1. ✅ 适合使用迭代器设计模式的场景

4.2. ❌ 不适合使用迭代器设计模式的场景

4.3. ✅ 举个金融风控例子

适合：遍历用户的多个信用卡账户，统一处理风控评分。

for (Account account : userAccountIterator) {
    scoreService.evaluate(account);
}

不适合：实时交易撮合引擎中，大量订单队列需要毫秒级处理，使用数组/队列遍历更高效，不宜引入自定义迭代器。

5. 迭代器设计模式实战示例

下面是一个在金融风控场景下，使用迭代器设计模式 + Spring 注解注入方式 实现的示例，适合处理多个风控规则依次执行的业务逻辑。

5.1. 🎯 场景描述

对信贷申请进行风控判断。每个申请会通过一系列规则（如黑名单、年龄检查、信用分检查），每条规则是一个策略，同时这些策略按顺序组成一个责任链。为了支持动态控制规则顺序，还使用迭代器遍历规则链。

5.2. ☕️ 项目结构

com.example.risk
├── RiskRule.java         # 策略接口
├── AbstractRiskRule.java # 模板实现
├── BlackListRule.java    # 黑名单规则
├── AgeLimitRule.java     # 年龄限制规则
├── CreditScoreRule.java  # 信用分规则
├── RuleChainContext.java # 责任链 + 迭代器控制
├── RiskRequest.java      # 入参
├── RiskResponse.java     # 出参
├── RuleConfig.java       # 自动注入规则列表
└── RiskService.java      # 风控服务入口

5.3. 风控请求/响应对象

@Data
public class RiskRequest {
    private String userId;
    private int age;
    private int creditScore;
    private boolean inBlackList;
}

@Data
public class RiskResponse {
    private boolean passed = true;
    private String failedReason;
}

5.4. 策略接口和抽象类（策略 + 模板）

public interface RiskRule {
    boolean evaluate(RiskRequest request, RiskResponse response);
    String getName();
}

public abstract class AbstractRiskRule implements RiskRule {
    
    @Override
    public boolean evaluate(RiskRequest request, RiskResponse response) {
        if (!doEvaluate(request)) {
            response.setPassed(false);
            response.setFailedReason(getName());
            return false;
        }
        return true;
    }

    protected abstract boolean doEvaluate(RiskRequest request);
}

5.5. 各种规则实现（策略 + 责任链）

@Component
public class BlackListRule extends AbstractRiskRule {
    @Override
    public String getName() {
        return "黑名单规则";
    }

    @Override
    protected boolean doEvaluate(RiskRequest request) {
        return !request.isInBlackList();
    }
}

@Component
public class AgeLimitRule extends AbstractRiskRule {
    @Override
    public String getName() {
        return "年龄限制规则";
    }

    @Override
    protected boolean doEvaluate(RiskRequest request) {
        return request.getAge() >= 18;
    }
}

@Component
public class CreditScoreRule extends AbstractRiskRule {
    @Override
    public String getName() {
        return "信用分规则";
    }

    @Override
    protected boolean doEvaluate(RiskRequest request) {
        return request.getCreditScore() >= 600;
    }
}

5.6. RuleChainContext（责任链 + 迭代器）

@Component
public class RuleChainContext {

    private final List<RiskRule> ruleList;

    @Autowired
    public RuleChainContext(List<RiskRule> ruleList) {
        // 可排序或通过配置动态控制顺序
        this.ruleList = ruleList;
    }

    public RiskResponse process(RiskRequest request) {
        RiskResponse response = new RiskResponse();
        Iterator<RiskRule> iterator = ruleList.iterator();
        while (iterator.hasNext()) {
            // 迭代器进行遍历
            RiskRule rule = iterator.next();
            if (!rule.evaluate(request, response)) {
                break; // 短路失败
            }
        }
        return response;
    }
}

5.7. Service调用入口

@Service
public class RiskService {
    
    @Autowired
    private RuleChainContext ruleChainContext;

    public RiskResponse evaluate(RiskRequest request) {
        return ruleChainContext.process(request);
    }
}

5.8. ✅ 使用方式示例

@RestController
@RequestMapping("/risk")
public class RiskController {

    @Autowired
    private RiskService riskService;

    @PostMapping("/check")
    public RiskResponse check(@RequestBody RiskRequest request) {
        return riskService.evaluate(request);
    }
}

5.9. 🧠 总结：设计模式用法回顾

如需添加动态配置规则链顺序、启用规则开关、分组规则集等功能，可以进一步引入配置中心或数据库控制，支持高扩展。

6. 迭代器设计模式思考

6.1. 🔁 常与迭代器组合使用的设计模式

在实战开发中，迭代器设计模式（Iterator Pattern）通常与以下几种设计模式组合使用，以增强集合结构的灵活性、扩展性、解耦性，尤其在领域模型、规则处理、任务调度等系统中非常常见：

6.1.1. 与责任链模式

场景：规则引擎、风控审核、流程编排

• 每个 handler/规则实现 RuleHandler 接口
• 用 List<RuleHandler> 通过迭代器逐个执行，遇失败中断

for (RuleHandler handler : handlers) {
    if (!handler.handle(context)) {
        break;
    }
}

6.1.2. 与策略模式

场景：算法选择、数据转换器、规则过滤器

• 每个元素是一个策略类（如计算利息、折扣策略）
• 迭代器控制策略的执行顺序，支持动态扩展

6.1.3. 与组合模式

场景：菜单树、组织结构、数据表头嵌套结构

• 组合结构的节点可以通过迭代器实现统一的遍历

6.1.4. 与模板方法模式

场景：日志采集、批量数据导出、统一操作步骤

• 各子类复用固定遍历结构，通过 doXXX() 定制操作逻辑

6.1.5. 与命令模式

场景：批量命令处理、回滚事务、脚本执行

• 一组命令对象放入集合，通过迭代器逐个执行或撤销

博文参考

• 迭代器设计模式
• 设计模式——迭代器设计模式（行为型）