Day 102: Adapting

Today was a pretty standard day, code-wise. I worked on #136, which displays all the missions the player has in case they need to be reviewed at any point. TraderMissions had dialogs for cargo, missions, weapons on board, etc, and they each had a different key you'd have to press to get to them; this time I was determined not to be so annoying. Thus I'd long ago made #62, a request for a show-everything-about-this-ship dialog.

Well, if you've been reading this blog you know by now that I just can't leave well enough alone. Rather than start immediately on the mission specific dialog, I decided to make a general dialog.

I discovered pretty quickly that I'd been thinking about this all along - the cargo dialog inherited from a ShipPartViewer that I'd obviously intended to be the parent of any such states. So if I wanted to view addons on the ship I could subclass it to create an AddonViewer, etc. (Indeed, I discovered, I'd actually created those viewers if not hooked them up to events)

Creating a subclass for every type I want viewed seemed... familiar somehow. It's exactly the sort of thing I created the adapters for, so rather than go through the comparatively simple process of writing a MissionViewer subclass of ShipPartViewer, I took the more difficult path of writing a PlayerMissionAdapter, then refactoring ShipPartViewer to use whatever adapter it was given for display purposes. That done, I could remove all the other ShipPartViewer subclasses entirely!

This sounds much more complex than it was, mainly because ShipPartViewer was already made to be extendable, so the retrofit was not very difficult. Unlike the weekend, I did not spend hours tracking down subtle continuation bugs. I just coded up a few adapters, fixed some typos when it broke, and was finished for the night.

I need more coding days like this one!