支付系统中的设计模式08：迭代器模式

下面再来看看运营部门提的另一个「变态」需求——商品抽检。出于质量及安全要求，需要对某些用户进行抽检其购买的商品，抽检方式是逐一检视。

这个其实也比较好理解，咱们每次坐飞机、高铁，或者地铁，都会看到有安检环节。因为目前公司经营的商品类目中，可能会有一些较为敏感的商品，如管制器具、粉末状物体等。而且公司领导层也不希望那些刷单用户蒙混过关，所以要对敏感商品和重点标记顾客做抽检。

另外需要澄清一个歧义：抽检是针对顾客而言，而不是商品，也就是说：抽查对象是某些用户购买的全部商品，而不是某些用户购买的某些商品。

稍稍想一想就可以知道，用户下单购买的商品清单肯定是一个列表，而所谓的抽检其实就是要遍历这个列表中的每个元素，然后看看有无敏感商品或刷单行为（比如连续购买了多个同类的活动商品，并且下单时间极为接近，但这里不考虑这些）。最容易想到的方法就是直接用for循环检察列表，这的确是最直接的办法，但笔者还是要重复前面讲过的：在有了简单的、容易想到的办法后，至少还要再深入思考一下还有没有别的更好的方法可以替代呢？——这就是普通玩家和顶尖高手之间一个很明显的区别之一——普通玩家都是陪别人玩，而顶尖高手都是自己跟自己玩。

Java的集合对象中，有一个叫做迭代器Iterator的，专门用来遍历列表元素的。但其实这个迭代器的概念并不是Java特有的。在GoF设计模式中，就有一种叫做迭代器模式。