我应该在 PHP 中使用哪种 Iterator 实现，为什么？
我正在尝试重构一个大型的旧项目，我注意到的一件事是一系列不同的迭代器实现：
while($iterator->moveNext()) {
$item = $iterator->current();
// do something with $item;
}
for($iterator = getIterator(), $iterator->HasNext()) {
$item = $iterator->Next();
// do something with $item
}
while($item = $iterator->fetch()) {
// do something with item
}
甚至是 StandardPHPLibrary (SPL) 迭代器允许
foreach($iterator as $item) {
// do something with $item
}
拥有如此多不同的迭代器（使用不同的方法循环遍历集合）似乎有很强的代码味道，我倾向于重构一切以 SPL 为标准。 Iterator 的这些实现是否有令人信服的优势，或者纯粹是个人喜好问题？
I'm trying to refactor a large, old project and one thing I've noticed is a range of different Iterator implementations:
while($iterator->moveNext()) {
$item = $iterator->current();
// do something with $item;
}
for($iterator = getIterator(), $iterator->HasNext()) {
$item = $iterator->Next();
// do something with $item
}
while($item = $iterator->fetch()) {
// do something with item
}
or even the StandardPHPLibrary (SPL) iterator which allows
foreach($iterator as $item) {
// do something with $item
}
Having so many different Iterators (with different methods for looping over collections) seems like a strong code smell, and I'm inclined to refactor everything to SPL.
Is there a compelling advantage to any of these implementations of Iterator, or is it purely a matter of personal taste?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SPL 版本绝对是最佳选择。 它不仅最容易阅读，而且现在已经成为 PHP 的一部分，因此将被更多的人所熟悉。
其他版本没有什么“问题”，但正如您所说，在一个项目中拥有所有这些不同的版本对任何人都没有帮助。
The SPL version is definitely the way to go. Not only is it the easiest to read, but it's a part of PHP now, so will be familiar to many more people.
There's nothing "wrong" with the others, but as you stated, having all these different versions in one project isn't helping anyone.
在我看来，简单地利用一个或多个 SPL 库作为界面在前端使用时往往不会那么难看。 然而，实施背后的支持可能会变得有点难看。
例如，我编写了一个迭代器，可以有效地迭代数据库结果集，以便永远不会从请求指针中获取从未请求过的结果，并且如果过早地获取了项目（即： $obj[5] ），它将查找所有将所需的结果存入内部缓冲区。
工作得非常好，你只是祈祷让幕后魔法永远不会失败的代码，因为当人们看到你使用看起来像数组的东西时，它会让人们感到困惑，而且它确实有“魔法”，但可能会失败:)
魔法让人们在赌注。 因此，请谨慎而明智地使用它，尽可能地使其工作原理变得显而易见。
我个人更喜欢这种
符号，因为它通常更加一致和可预测。
样式表示法在功能上是相同的，但至少您可以减少对它表面上如何工作的猜测。
Imo, simply utilising one or more of the SPL libraries as an interface tends to be less ugly in use at the front end. However, the backing behind the implementation can get a bit ugly.
For instance, I wrote an iterator that efficiently iterated a database result set, so that results that were never requested were never fetched from the request pointer, and if items were prematurely fetched ( IE: $obj[ 5 ] ) , it would seek all the required results into an internal buffer.
Worked wonderfully, you just pray that code that makes the magic behind the scenes never fails because it confuses people when they see you use something that looks like an array, and it does "magic" which can fail :)
Magic got people burnt at the stake. So use it carefully and wisely, possibly make it obvious how it works.
My personal preference is for the
notation for it is generally more consistent and predictable.
style notation is functionally identical, but at least you have less guesswork how it works on the surface.