I found that confusing at first too. However, now it makes sense. It
seperates interface from implementation. The IEnumerable method signature,
GetEnumerator(), could have been included in the IEnumerator interface,
however that would require your class implement all the other methods (i.e.
MoveNext) when all it really wanted to do was return an object of type
IEnumerator. For example, you could have a class that allows an object
(that implements IEnumerator) to be stored during construction or set in a
method/property. In that case, your class does not care about implementing
IEnumerator methods, it just needs to return an instance of an IEnumerator
when GetEnumerator() is called on its IEnumerable interface. It allows you
to have multiple Enumerators for your class without having to implement the
IEnumerator methods in your class.
--
William Stacey, DNS MVP
"Peter Rilling" <pe***@nospam.rilling.net> wrote in message
news:eD**************@TK2MSFTNGP10.phx.gbl...
A design pattern question.
As you know, an enumerator in .NET is broken into two interface
(IEnumerable and IEnumerator). Is there a benefit in having two interfaces? Why not
just have the IEnumerator interface with the methods that interact with
the collection?
