Feeds

To iterate is human

Iterator versus the Enumeration Method

Choosing a cloud hosting partner with confidence

In the previous article, I made the following observation:

A collection that holds its elements but doesn't allow you to traverse them is unlikely to prove popular. There are many ways to offer traversal, but if the caller needs to be able to know the position of elements in some way there are essentially only three general designs that keep the collection's internal representation hidden from the caller.

And a reader made the following comment:

A fourth option, which is in the general case superior to all three of your options, is the internal iterator. It delegates management of the iteration to the collection, rather than adding repetitive boilerplate to your functional code.

In this particular case, the design pattern mentioned is also known as the Enumeration Method pattern. The use of this pattern was mentioned in the article, along with a link to a corresponding article, although it appears that it was overlooked.

However, the posted comment touches on a whole topic area that deserves more attention than there was either space or topic focus for in the previous article. In fact, it deserves at least a whole article!

In essence, where Iterator is normally characterised by the introduction of an additional kind of object that performs iteration over some kind of collection, Enumeration Method introduces a method on the collection that calls back on a piece of supplied code for each element in the collection. The key benefit here is that you are only dealing with a single unit of design responsibility. All the mechanics of iteration are contained within the collection. Very compact, very cohesive. Nice — just what we want.

However, there are some other considerations at play: some are related to matters of perception; others are related to questions of practice; the rest are related to requirements and design goals; all are related to understanding the context that frame, and the forces that drive, a particular pattern's application.

The Gang of Four tried to shoehorn this additional iteration pattern, in the guise of Internal Iterator, into their write up of Iterator, but it must be said with limited success.

Its presence is fairly low key, with most of the detail tucked away towards the end of the pattern write up, the last item in the Sample Code section. The unification of these two different design approaches was something of a compromise to try to accommodate a single iteration pattern for all OO-related languages. Specifically, an attempt to square a C++ view of the world with a Smalltalk view of the world... which is always a challenge.

However, the fundamentally different design structures, philosophies, and trade-offs of the two approaches undermine any claim that they can be considered the same pattern. A pattern represents a recurring design solution, with an associated set of consequences, to a recurring problem, whose forces are understood and arise within a specific context.

It turns out that although both can be characterised in the general sense as iteration patterns the similarity ends there: the two approaches have almost nothing in common; the consequences of applying each one have almost nothing in common; indeed, even the problem forces that they resolve differ in the detail.

Internet Security Threat Report 2014

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Facebook, working on Facebook at Work, works on Facebook. At Work
You don't want your cat or drunk pics at the office
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
First in line to order a Nexus 6? AT&T has a BRICK for you
Black Screen of Death plagues early Google-mobe batch
prev story

Whitepapers

Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Designing and building an open ITOA architecture
Learn about a new IT data taxonomy defined by the four data sources of IT visibility: wire, machine, agent, and synthetic data sets.
How to determine if cloud backup is right for your servers
Two key factors, technical feasibility and TCO economics, that backup and IT operations managers should consider when assessing cloud backup.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.