Orientation

I have slightly bad eyesight. I have to squint in fast food restaurants to see what’s on the menu. And when I get off the subway, I can’t immediately locate which exit to take, as the signs are often too far away. So I must walk up closer, and sometimes I must turn around and walk the other way. However, this won’t be a problem much longer, as I’m picking up a pair of glasses on Friday, but I thought about this as I did some refactoring (improved the design of the code) at work the other week.

More on that later, because thinking about the subway made me think of the subway in Paris. I had great troubles to find which exit to take to get on a different line. As I remember it, the lines were color coded on the subway map, but those colors weren’t used on signs. (This was in 1996, I think.) I guess I had to match the names of the end stations on the map to the signs, or something like that. Anyway, I remember that I, on several occasions, realized I was on the wrong platform, and had to go back to the platform I came from and take the other exit.

The London Underground is brilliant in this regard. The exits are clearly indicated and, on most platforms, it doesn’t matter which exit you take, as they lead to the same tunnel. To change to another line, you find out where to go as you reach the end of the tunnel, where there are clear signs indicating this.

Ok, now to my point. The system I am working on was fairly well-designed, but nearly all classes were in the same package. I sat down and tried to partition the classes into related groups which would map to new Java packages. First, I named the leaf packages “pages” (as in web pages), “logic,” and “data” (as these were names we had used for subdirectories already). But then I decided to use the more familiar names “view”, “control,” and “model” – as in the Model-View-Controller (MVC) design pattern.

The reason for this is orientation. It’s a good thing if you can immediately get a sense of where in the system you are, as you are reading a source code file. If you know that the class you’re looking at is in the package called “model”, you instantly know that it probably is presented to the user, using code in the packages “control” and “view” – provided that you’re familiar with the MVC pattern.

The user interface of the application is tabbed. It has four different tabs which lead to four different parts of the application, mapping to four different types of user tasks. Above the model, view, control packages are packages that map to these parts of the system. So if the programmer has ever seen the UI, he or she will also know how the inspected class relates to the rest of the system.

The subway analogy is that as you get off the train, even if you haven’t been on the station in question before, you should know where to go to get where you want. After a while, you’ll learn to navigate a subway system, despite how poorly signed and incoherently designed. You will get over the confusion, but it’s a sad waste of time.