Refactor
I spent last week coding up a new feature for ProjectF. As I mentioned before, I’m using TDD and I’ve been refactoring as I go. I ended up with a view, a UIViewController, and a behavior model. However, when I was “done” I took at step back and looked at what I had. I found some of the classes a little larger than I would have liked. At about this time I watched this Sandi Metz video on SOLID design principles and felt like I should apply these principles to iOS and, in particular, to my new classes. I started off working toward single responsibility in my controller.
Single Responsibility with UIViewController
A while back I had read and embraced A Rule of Thumb For Controller Code which recommends writing a single method in a ViewController to update the entire UI. In this way, all the logic for updating the UI, which may include many rules, can be encapsulated in one place. This facilitates reuse and eliminates the problem of forgetting to apply any of the special rules when updating the UI for a specific action.
For my new ProjectF ViewController I had an update method with a few short helper functions. While looking over the class I realized that updating the UI was one of several responsibilities put upon my ViewController. The other responsibilities included UIViewController lifecycle management and handling UI actions. With the goal of single responsibility I set about splitting the update functionality into a separate class. The combination of the “rule of thumb” and single responsibility go hand in hand. By centralizing the update code into a single update method, it became apparent that UI update is an independent responsibility and made it straightforward to extract the behavior into a separate class.
Updater
I created a new Updater class and associated specs and started moving tests, IBOutlets, and code over to the new files. First, I decided that the IBOutlets connecting the view needed to move to the Updater. I use Interface Builder and had originally connected the views to the ViewController. I now needed Interface Builder to connect the views to the Updater. To do this, I did the following:
- In Interface Builder, I added an object to my ViewController
- I set the object’s class to my new Updater class.
- I added IBOutlets to my Updater class.
- I connected the views to my Updater’s outlets.
- I added an IBOutlet to my controller of type Updater.
- I connected the Updater object to the view controllers updater outlet.
I moved code from the ViewController to the Updater to register for the behavior model’s events and set up the Updater to update when the events were posted.
The result is quite nice. This refactoring made it easier to test the UI updates and simplified both classes. I believe my client will request some UI updates to this scene and there are definitely still changes to be made in terms of filling in final artwork. I hope that the refactoring that I’ve done will make these future changes easier to implement.
IBOutletCollections
There was one more interesting piece to this exercise. The scene in question has a set of buttons that all behave the same way. These buttons are used to launch a selection menu in order to pick an item. Once an item is picked, it’s stored in an array in the model and the button label is updated to reflect the current selection. When the button label is updated the value is taken from the model. This keeps all the business logic in the model. The takeaway here is that there needs to be a consistent mapping between the buttons in the IBOutletCollection and array in the model so that the action can update the array based on a specific button being tapped and the Updater can fetch the right data from the array for a given button’s update.
My first attempt at the Updater refactoring still needed two IBOutletCollections, one in the Updater and one in the ViewController used by the actions. The two IBOutletCollections stored the same buttons, but not in the same order because the order of items in an IBOutletCollection is undefined. The traditional way to identify items in an IBOutletCollection is to user Interface Builder to set the tags on the underlying UIView objects. The tags can be set up and used as simple indices, if desired. Using this traditional scheme was my first thought for building a consistent mapping of buttons to items in the model’s array. But, I realized this would introduce a dependency between my views and the Updater or ViewController. It wouldn’t make sense for the view to define the mapping shared between the ViewController, Model, and Updater. The view itself would never make use of the mapping.
I decided instead, to set up the mapping at run time. I used the tag properties as they provide convenient storage, but I did not assign them using Interface Builder. Instead, I had the Updater set the tags by simply iterating over the IBOutletCollection and assigning each tag in order. Then, I used the tags as indices into the model’s array from both the Updater and the ViewController. This gave me a consistent mapping and allowed me to remove the IBOutletCollection from the ViewController as the action could now just reference the tag from the sender argument:
- (IBAction)buttonAction:(UIButton *)sender { int arrayIndex = sender.tag; // … } |
Examples
I’ve posted JKUpdaterExample on GitHub. Take a look and browse through an example of this pattern and get an idea of how to apply it in your own projects.
Conclusion
Overall, I’m very happy with this design. The Updater class provides a nice object to own the UI and separates out an independent chunk of functionality. I plan to continue using this pattern to write ViewControllers in the future.
The next step is to continue with the single responsibility principle and separate the actions into separate classes. The controls in this scene fall into a couple of different categories and it might make sense to have an Action class for each category. After an action refactoring, the ViewController itself will be left just handling the view lifecycle which seems exactly right.