I'd say that, ideally a class should have a single, well defined area of responsibility. However, that's not always possible or pragmatic.

Look at a class like UIButton. It has methods dealing with the button's location and size, the button's appearance, and managing user interactions with the button. Also, any "single responsibility" can probably be divided into multiple sub-responsibilities (in all but the most simple case). For example, we could claim that the UIButton has a single responsibility--to represent a user interface element on screen that the user can press to trigger actions. All the other details are then simply aspects of the greater, umbrella responsibility.

So, at some point, it comes down to personal preference. How much complexity are you willing to put up with--and how much of the complexity can you pragmatically move off to other classes?

UIDocument, by itself, already does a number of things. It provides atomic, automatic background saving of our model. It automatically synchronizes read/write operations with the iCloud service (if saving to the iCloud container), it alerts us to conflicts or other changes to the document state.

Unfortunately, we still have to implement a lot as well:

* Need to tell it how to save and load its data
* Need to deal with conflicts
* Need to deal with state changes
* Need to alert the document whenever a change has occurred.

We need to make a subclass of UIDocument to handle these tasks. The document also needs access to our WeightHistory data. There are two basic approaches we could use here.

1) Make WeightHistory a subclass of UIDocument. (the approach from the book).
2) Make a separate UIDocument subclass. Have it hold a reference to our WeightHistory object.

Either option can lead to unwanted complexity. In option 1) we're mixing WeightHistory's data management code with UIDocument's document management code. In option 2, we need to determine how the two classes interact. Do we strictly access WeightHistory through UIDocument? How do we coordinate changes to WeightHistory with alerting UIDocument about the change? etc., etc.

Given WeighHistory's relative simplicity, I thought that the first option would produce the cleanest, most straightforward code. However, I'd encourage you to experiment with Option 2, and see if you like it better. (UIManagedDocument largely follows the Option 2 rout--it maintains a reference to the Core Data managed object context).

Also, we have a few Objective-C tools that can help us manage complex classes. If a single class file is becoming too long, we can always break it into categories. For example, we could move all the UIDocument-based methods into a category on WeightHistory.

In many ways, this is the best of both worlds. We still have a single class (which, pragmatically, is the easiest solution for this situation), but we can break the code into separate files, keeping each file small and focused. Apple does this for a lot of their more-complex classes.

I hope that helps,

-Rich-