C#中FCL迭代器模式的一点问题

简介: 迭代器模式是GOF23种模式中的一种,目的是为了提供对集合的遍历。为什么要实现迭代器模式: 假设存在一个数组,我们的遍历模式可能是采用依据索引来进行遍历。又假设存在一个HashTable,我们的遍历模式就可能按照键值来进行遍历。

迭代器模式是GOF23种模式中的一种,目的是为了提供对集合的遍历。为什么要实现迭代器模式:

假设存在一个数组,我们的遍历模式可能是采用依据索引来进行遍历。又假设存在一个HashTable,我们的遍历模式就可能按照键值来进行遍历。无论是哪个集合,如果它们的遍历没有一个公共的接口,那么我们的客户端进行调用的时候,相当于是对具体类型进行了编码。这样以来,当需求变化的时候,就必须修改我们的代码。并且,由于客户端代码过多的关注了集合的内部实现,代码的可移植性就会变得很差,这直接违反了面向对象中的开闭原则。于是,迭代器模式就诞生了。现在,不要管FCL中是如何实现该模式的,我们先来实现一个我们自己的迭代器模式。

代码清单:

 
  
public class Program
{
static void Main( string [] args)
{
// 使用接口IMyEnumerable代替MyList
IMyEnumerable list
= new MyList();
// 得到迭代器,在循环中针对迭代器编码,而不是集合MyList
IMyEnumerator enumerator
= list.GetEnumerator();
for ( int i = 0 ; i < list.Count; i ++ )
{
object current = enumerator.Current;
enumerator.MoveNext();
}
while (enumerator.MoveNext())
{
object current = enumerator.Current;
}
}
}

/// <summary>
/// 要求所有的迭代器全部实现该接口
/// </summary>
interface IMyEnumerator
{
bool MoveNext();
object Current { get ; }
}

/// <summary>
/// 要求所有的集合实现该接口
/// 这样一来,客户端可以针对该接口编码,而无需关注具体的实现
/// </summary>
interface IMyEnumerable
{
IMyEnumerator GetEnumerator();
int Count { get ; }
}
class MyList : IMyEnumerable
{
object [] items = new object [ 10 ];
public IMyEnumerator MyEnumerator { get ; set ; }
public object this [ int i]
{
get { return items[i]; }
set { this .items[i] = value; }
}
public int Count
{
get { return items.Length; }
}
public IMyEnumerator GetEnumerator()
{
if (MyEnumerator == null )
{
return new MyEnumerator( this );
}
return MyEnumerator;
}
}

class MyEnumerator : IMyEnumerator
{
int index = 0 ;
MyList myList;
public MyEnumerator(MyList myList)
{
this .myList = myList;
}

public bool MoveNext()
{
if (index + 1 > myList.Count)
return false ;
else
{
index
++ ;
return true ;
}
}
public object Current
{
get { return myList[index]; }
}

}

MyList模拟了一个集合类,它继承了接口IMyEnumerable,这样,在客户端进行调用的时候,我们就可以直接使用IMyEnumerable来进行声明变量,如代码中的:

            IMyEnumerable list = new MyList();

如果未来我们新增了其它的集合类,那么针对list的编码即使不做修改也能运行良好。在IMyEnumerable中声明的GetEnumerator方法返回一个继承了IMyEnuerator的对象。在MyList的内部,我们默认返回MyEnumerator。MyEnumerator就是迭代器的一个实现,如果对于迭代的需求有变化,我们可以重新开发一个迭代器,然后为MyList指定该迭代器就可以了。注意客户端的代码中,迭代的过程我们分别演示了for和while循环。因为使用了迭代器的缘故,两个循环都没有针对MyList编码,而是实现对迭代器的编码。

理解了我们自己实现的迭代器模式,就相当于理解了FCL中提供的对应模式。其实,上文代码中我们的接口名称中都加入了“My”字样,FCL中有相对应的这类接口,只不过我们为了演示的需要,增删了接口中的部分内容,但是大致的思路是一样的。

但是,问题也带来了。当集合类型因为某种需求,需要一个自定义迭代器的时候,FCL没有给我们公开这样的接口。所有的FCL集合,无论是泛型还是非泛型集合,都提供了GetEnumerator方法,没有提供SetEnumerator方法。注意到在我自己实现的集合类MyList 中,我公开了迭代器属性:

        public IMyEnumerator MyEnumerator { get; set; }

这样一来,可以让集合有新的迭代需求的时候,实现自己的迭代器。当然,如果没有为集合对象指定迭代器,那么它会返回一个默认迭代器,如下:

 
 
public IMyEnumerator GetEnumerator()
{
if (MyEnumerator == null )
{
return new MyEnumerator( this );
}
return MyEnumerator;
}

公开迭代器属性的好处就是,一旦迭代需求变化,我可以随时扩充我自己的迭代器,只要它继承IMyEnumerator接口。所以,为什么微软提供的FCL不让我们扩充迭代器呢?

Creative Commons License本文基于 Creative Commons Attribution 2.5 China Mainland License发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 http://www.cnblogs.com/luminji(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。
目录
相关文章
|
3月前
|
设计模式 Java 数据挖掘
聊聊Java设计模式-迭代器模式
迭代器(Iterator)模式,也叫做游标(Cursor)模式。我们知道,在Java 容器中,为了提高容器遍历的方便性,我们利用迭代器把遍历逻辑从不同类型的集合类中抽取出来,从而避免向外部暴露集合容器的内部结构。
44 0
聊聊Java设计模式-迭代器模式
|
4月前
|
设计模式 uml C++
行为型 迭代器模式
行为型 迭代器模式
20 0
|
6月前
|
设计模式 存储 算法
设计模式~迭代器模式(Iterator)-20
迭代器模式(Iterator Pattern)是Java和.Net编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素,不需要知道集合对象的底层表示。迭代器模式属于行为型模式。迭代器模式已经被淘汰,java中已经把迭代器运用到各个聚集类(collection)中了,使用java自带的迭代器就已经满足我们的需求了 目录 迭代器模式(Iterator) (1)优点 (2)缺点 (3)使用场景 (4)注意事项 (5)应用实例: 代码
25 0
|
9月前
|
设计模式 存储 Java
迭代器模式
迭代器模式(Iterator Pattern)是一种行为型设计模式,它提供了一种顺序访问聚合对象中每个元素的方法,而不暴露其内部实现。
57 1
|
10月前
|
容器
关于迭代器模式我所知道的
关于迭代器模式我所知道的
40 0
|
JavaScript 前端开发
简单理解迭代器模式
这几天研究了一下迭代器模式,期间有一段时间经常搞不太懂一些概念与概念之间的关系,今天来整理一下。
102 0
|
设计模式 算法 Java
Java设计模式 ->迭代器模式
Java设计模式 ->迭代器模式
64 0
|
设计模式 存储 容器
我学会了,迭代器模式
迭代器模式属于行为型模式,这个类型的设计模式总结出了 类、对象之间的经典交互方式,将类、对象的行为和使用解耦了,花式的去使用对象的行为来完成特定场景下的功能。
83 0
我学会了,迭代器模式
|
Java 容器
迭代器模式
迭代器模式
82 0
|
Java uml 容器
被用到炉火纯清的迭代器模式
迭代器模式(Iterator),提供一种方法顺序访问一个聚合对象中的各种元素,而又不暴露该对象的内部表示。
94 0
被用到炉火纯清的迭代器模式

热门文章

最新文章