网站如何做浮窗,wordpress小米路由器3,网络营销就是网站营销,人事外包Iterator模式的几种用法 在网络上看帖子时发现不少模式的初学者对Iterator模式的理解仅仅停留在从类库的容器类取得Iterator来遍历容器中的内容的程度。 因此在这里写几个例子#xff0c;来加深大家对Iterator模式的理解。 对容器中元素的访问涉及到3个方面。 1#xff0e;容…Iterator模式的几种用法 在网络上看帖子时发现不少模式的初学者对Iterator模式的理解仅仅停留在从类库的容器类取得Iterator来遍历容器中的内容的程度。 因此在这里写几个例子来加深大家对Iterator模式的理解。 对容器中元素的访问涉及到3个方面。 1容器的类型 2检索容器内元素的方法 3对元素的操作 比如说我们有一个表示书店的book_store类。里面保存了各种各样的book类的实例。 book类有name和type两种属性。表示书的名字和类别。 因此book_store类内部会用一个容器来保存book的实例。比如list。 class book { public: string name; string type; }; class book_store { private: listbook m_books; }; 我们现在有这样一个简单的应用那就是输出所有的书名到屏幕。 那么我们来看一下在引入Iterator模式前有那几种实现方法各有什么缺点。 1给book_store类增加一个print_book_name的函数。来实现这个功能。 这样做的缺点有两个 1将输入输出逻辑和业务对象绑定在一起导致了今后系统难以变更。 2输出逻辑和内部实现绑定。 比如现在要把输出到屏幕改成输出到log文件的话那么就需要修改print_book_name了。 2给book_store类增加一个get_list函数。然后写一个print_book类来负责打印书名的列表。这是一个初学者常用的方式。表面上看来似乎两个类各担其责一个表示业务对象一个负责打印。 如果需要打印到log文件的话只要新增加一个log_book类book_store和print_book都不受影响。解决了上面的这个问题。 这样做的缺点是 1把book_store类的内部实现给暴露出来了违反了封装的原则。 如果现在把内部容器类型从list换成了vector的话就要修改输出逻辑了。也就是说要同时改写print_book类和log_book类。 3增加一个list和vector类共同的基类/接口比如I_container。然后给book_store类增加一个get_books函数返回I_container。 这在一定程度上解决了上面的问题。但是并不彻底。应为还是暴露了内部的实现只不过从list上升到了I_container。 · 如果现在系统发生了变化book_store不再在本地保存books了而是需要通过网络取得的话print_book和log_book就无法对应了。 · 另一个限制是我需要一个新的机能那就是打印所有type为”烹饪书”的机能的话就需要一个print_cook_book类了而这里边的格式化代码和输出代码和print_book是相同的。重复代码是维护的噩梦。 接下来我们看一下Iterator模式如何解决以上的这些问题。 首先我们引入一个I_iterator的Interface。 然后创建一个I_iterator的实现类all_book_iterator。这个类可以迭代book_store中的所有book。 接下来创建一个print_book类从I_iterator中取得每一个book然后打印到屏幕。 下面我们看一下如何对应上面的这些需求变更。 1要求输出到log文件 追加一个log_book类其他都类都不需要改变。 2将内部容器从list变成vector。 修改iterator中的相关代码。Iterator的使用者不会受到影响。 3从网络取得数据。 修改iterator中的相关代码。Iterator的使用者不会受到影响。 4按照type检索 在iterator中添加一个type的属性或者是构造一个新的type_search_iterator。 在iterator中把不符合检索条件的book过滤掉。 5按照某一特定顺序输出book名到屏幕或是log文件。 实现一个按该顺序输出的iterator。 6以同样的方式打印cd_store。 实现对应于cd_store的iterator。 可见iterator模式在各种iterator中封装了检索元素的方法。 将容器和对容器中元素的操作完全隔开。 大大增加了代码的可重用性。
