For very similar purpose I once defined a CircularIterator class (also in JS, where it's not available as itertools.cycle in Python for example) which wrapped a

For very similar purpose I once defined a CircularIterator class (also in JS, where it's not available as itertools.cycle in Python for example) which wrapped any kind of collection and had next, prev, get and set methods (at the time I was yet to learn about Smalltalk's streams - the methods would be named like nextPut and next would have an optional argument, but I digress :)). In essence it was exactly the same thing you did, but due to it being OO, I managed to reuse it quite a few times since (having something which cycles between three states on click is a breeze now). The thing here is that the problem of "wrapping" a sequence instead of throwing some kind of Out-of-bounds-the-sky-is-falling error is pretty common and it deserves generic solution. You - and structural programming, for that matter - trapped a solution to this problem inside a solution for carousel. That's exactly one of more important things OOP came to fix. But I guess it's true that "the OO people tend to only teach modelling on problems with really quite obvious decompositions". I think nearly 100% of examples of OO in tutorials and books are completely useless and that there should be some major change in the way of teaching and thinking about OO. For me, that I managed to come up with a useful abstraction back then was pure luck. Later, when I saw Smalltalk - and worked in it for some time - I finally understood what OO is about and how beautifully it can simplify and generalize problems which would be one-off with procedural/structured programming.