finalizing the Iterator API

Casper Boemann cbr at
Tue Jul 6 15:00:45 CEST 2004

> If you and Cyrille can hammer out a final design for the API, then we can
> start implementing and moving forward.

Ok Cyrille, so what do you think of the .h file

I have some refinement ideas myself already:

I imagine that the iterators are friends of the KisTileMgr class. That way
we can make more functions of the tilemanager private, see GOF (that is one
great book) for more info.

As also suggested by GOF only the super iteratorclass should be friend, but
provide protected access methods for subclasses of iterator to use.

If you don't have GOF I'll explain some more on request.

>From you experience with the other iterators, are there anything you would
like to change navigationvise - now that we have the chance..

GOF uses done() to check for reaching the end. You use another iterator to
compare with. GOF also lists your method as an alternative (also lists an
alternative of advance() returning a status) so I'm not saying there is
anything wrong. It's just a matter of taste, and now that you have had some
experience with use, you might have som wishes.

Also if we should think Boudewijn wish of decoupling the tilemanager from
the paint device (allowing different "tilemanagers") into our design we need
a factory method pattern, meaning a larger number of Iterator classes. The
factory would be the paint device and the concrete factories would be
TileMgr, CacheMgr etc. The factories should be done now, but the Iterators
can be refactored later if the need ever arises (I don't think it ever
will). But now I have brought it up.

best regards
Casper Boemann

More information about the kimageshop mailing list