迭代器设计模式（四） - 使用场景

前言

迭代器设计模式系列文章
迭代器设计模式（一） - 简介
迭代器设计模式（二） - 早期qq和微信用户登录系统一般写法
迭代器设计模式（三） - 早期qq和微信用户登录系统迭代器设计模式写法
迭代器设计模式（四） - 使用场景
迭代器设计模式（五） - 底部导航栏

1. 使用场景

---

1>：类似上一节的早期qq和微信登录系统的例子，如果只有2个系统：

a：只需要在测试客户端Client中创建qq和微信用户系统对象；
b：然后定义一个查询用户信息的方法 queryUserInfo("Novate" , "123" , qqUserSystem.iterator()) ;
c：自己只需要给第三个参数传递对应系统的迭代器方法就可以；

也就是说，不管后期会增加几个用户系统，只需要创建多个用户系统对象，然后给第3个参数传递对应系统对象的迭代器方法就可以，queryUserInfo()具体的方法不需要改变，其他任何地方也不需要修改；

2>：比如有4个人开发，现在有一个人需要显示ListView或者RecyclerView列表，但是数据已经被存入到数据库了，而且存储到3个库里边；

如下图所示：

迭代器模式应用场景2.png

比如第一张表：返回的是 List集合，是因为对于第一个后台的人可能返回List集合的话，对他来说是最方便的，但是如果你非要让他转为set集合再返回给你，可能对于他来说会比较麻烦；
同样的，对于第二张表：返回的是 Set，是因为 返回Set集合对他来说可能比较方便，但是如果你非要让他转为 List集合再返回给你，可能对于他来说会比较麻烦；
同样的，对于第三张表：返回的是 Object[]数组，是因为 返回Object[]数组对他来说可能比较方便，但是入股你非要让他转为 List集合再返回给你，可能对于他来说会比较麻烦；

基于这种情况，这个时候有2种解决方案：
A：第一种：在开发之前大家都必须商量好，返回那种数据类型，这样每个人都必须返回同一种类型就可以，但是这样可能灵活度不够，就可以采用下边第二种方案；
B：第二种：什么都不要说，直接返回迭代器就可以，意思就是你不需要管我返回的是List集合、Set集合、还是Object[]数组，我会把这些都转为迭代器，并且保证你app获取后台数据返回的是迭代器就ok，你不需要管后台接口是如何实现的；