View controllers are glue-like components that hold an app together. They are responsible for the moderation between the model and the view layer. As moderators, they are highly-specialized according to the needs of the model and the user interface they belong to. As a result, the controller layer is often not reusable in other parts of the app, or even in other apps.

As the controller is responsible for many different tasks, it often becomes large. It is a good practice, therefore, to construct the controller layer of a specific feature out of different controller classes. For instance, beginners often put their networking code into the same class that is responsible for filling the UI with information. This results in a so-called god class, a class that knows and controls everything.

Such classes are hard to write, read, and maintain, and should, therefore, be avoided. To make the view controller that's showing the list of items clean, we need to separate the data source and delegate the table view out into its own class, the data provider. The communication between the view controller and the data provider can be defined using protocols. This way, you can swap one implementation for another by just conforming to the protocol. In addition to this, when defining a protocol, you need to think about how to make the API surface (that is, the number of methods that are exposed to other classes) small and easy to understand. The result of this will be a modular architecture with a clear separation of tasks into different classes and structs.

In this chapter, we will build the different classes that make up the controller layer of our app. In a later chapter, we will put all the modules we have implemented together in a running app.

We'll cover the following topics in this chapter:

• Implementing ItemListViewController
• Implementing DataProvider

• Implementing DetailViewController
• Implementing InputViewController