Software design patterns are not hard-and-fast programming rules, but are general, reusable solutions to commonly occurring problems in software design. Over the years, people have identified such patterns and given them names. The details often vary depending on the context and who you are talking to. Having design patterns helps avoid re-inventing the wheel in each project and choosing solutions to problems that have been visited before. It also provides a vocabulary for us to talk about how to implement our projects.

Before we begin the project, let's talk about some software design patterns that we are going to use. These include the following:

• Model-view-controller
• Object encapsulation
• Class inheritance
• Event observer pattern

In this project, we use a Model-View-Controller (MVC) architecture. Model is your data, view is the screen layout, and controller manages the events from the user, making sure the screen is updated with the correct data. See the illustration ahead:

The view is independent of the content data. Think of it as a layout template. The view is handed some data (model) to show on the screen. In this app, the instructional steps that explain how to change a tire are the data. Then, a controller ties it all together, keeping track of which step the user is currently viewing, and responds to user input to navigate between steps.

We will create an Instruction Model class that parses the instructions data, loaded from an external database file, into C# objects that we can use. It will implement a simple object-oriented programming (OOP) interface using C# classes. The data will come from an external spreadsheet CSV file. There will be a public function, GetInstructionStep(), that returns the data for a specific record of data, which we'll name InstructionStep.

A characteristic of OOP is that objects keep their data as private as possible, limiting access by other parts of the system through its public functions interface. This is referred to as encapsulation, as illustrated ahead:

We will also create an Instructions Controller that manages the UI and the current state of the application. It makes sure the UI is displaying the correct information. It will provide functions, NextStep() (called by the Next button) and PreviousStep() (called by the Previous button).

The controller will also handle an OnInstructionsUpdate event, which forwards events to the Title, Body Text, Image, and Video UI elements that are listening and respond by adding the data to the screen. Using this event-driven pattern will provide a clean way to ensure the UI is updated any time the user presses the Next or Previous buttons. This event-observer design pattern, which we have used often in Unity projects, is as illustrated ahead.

As you probably realize, in object-oriented programming we talk a lot about classes and objects. Classes define the properties and functions of a type of object. And objects are specific instances. A Dog class says any dog has four legs and barks. An instance of Dog may be named Spot and belongs to you. A Dog is a kind of Mammal (for example, derived from the Mammal class). If mammals nurse their young, Dog inherits the property of nursing their young from Mammal.

In Unity, your scripts usually inherit from a base class provided by Unity itself, called MonoBehaviour. These scripts get all the MonoBehaviour goodness that Unity provides, including the Start() and Update() methods that you can define, and are called from the engine. In our project, we will also create a base class, InstructionElement, and then develop new classes that inherit from it. The class inheritance of InstructionElement and its subclasses are illustrated ahead:

We will talk about these design patterns later in the chapter as we use them in the code. But, first, let's build a user interface. OK, let's go!