This is a short post about an observation from the real world about playlists. I use the amazing SanDisk Sansa Clip+ music player with the great, open-source Rockbox firmware to listen to dozens of podcasts. The official firmware has weird quirks about separating music and podcasts, so that you can’t create a playlist of podcast episodes. Rockbox is much better in this. I’ve noticed a very interesting thing after using podcast playlists for some time: they represent the (object-oriented) Iterator design pattern in the real world.
The benefits of using playlists:
The main one; this is basically the idea of abstraction in computer programming: separation of how the next episode is determined from the point of when the next episode is used. When an episode ended, I typically don’t want to think and select the next one, but want another one to listen to. Playlists separate myself (or someone else!) in the past when I was selecting the episodes from myself in the present when I listen to them.
- With the iterator, the client is separated from the internals of the data structure: it asks for the next element and doesn’t know/care about how it is produced.
I save time by entering this episode selection mode once in some period of time instead of doing it every time after an episode ended. This may seem trivial, but I have to press a few buttons to enter the file manager, recollect what I listened to and what I wanted next, then play it. In the episode selection mode, I enter the file manager once, recollect the history, think of the next episodes and add them in one batch.
- This may be less applicable to programs. One thought: the client may prepopulate the iterator-implementing entity with its elements and give it to the client directly to eliminate the context switches from the client to the producer and back.
It may be inconvenient to look for the next episode manually in some situations, whereas with a playlist you just press Next.
- In a program, it is not just “inconvenient” to get the next element manually, but it is a bad design and a low level of abstraction between modules to do that.
The drawback here is that the listener depends on the order and number of episodes in the playlist by default. It is possible to rearrange/recreate a playlist, but if done often, it defeats the purpose and benefits of the solution.
ps. If I understand correctly, the Iterator pattern in functional programming is flipped. In OOP, the client asks for the next element of a structure repeatedly and does actions on them. In FP, the client uses the common functions like
map on the structure, providing the action to do on every element.