Understanding structures, classes, and instances

In the previous chapter, you learned some of the basics of the object-oriented paradigm, including classes and objects, which are also known as instances. We started working on an app required by an acrylic paint manufacturer that wanted to take full advantage of the popularity of a popular YouTuber, painter, and craftswoman. We ended up creating a UML diagram with the structure of many classes, including their hierarchy, properties, and methods. It is time to take advantage of the Playground to start coding the classes and work with them.

In Swift, a class is always the type and blueprint. The object is the working instance of the class, and one or more variables can hold a reference to an instance. An object is an instance of the class, and the variables can be of a specific type (that is, a class) and hold objects of the specific blueprint that we generated when declaring the class.

It is very important to mention some of the differences between a class and structure in Swift. A structure is also a type and blueprint. In fact, structures in Swift are very similar to classes. You can add methods and properties to structures as you do with classes with the same syntax.

Tip

However, there is a very important difference between structures and classes: Swift always copies structures when you pass them around the code because structures are value types. For example, whenever you pass a structure as an argument to a method or function, Swift copies the structure. When you work with classes, Swift passes them by reference because classes are reference types. In addition, classes support inheritance, while structures don't.

There are other differences between classes and structures. However, we will focus on the capabilities of classes because they will be the main building blocks of our object-oriented solutions.

Now, let's move to the world of superheroes. If we want to model an object-oriented app to work with superheroes, we will definitely have a SuperHero base class. Each superhero available in our app will be a subclass of the SuperHero superclass. For example, let's consider that we have the following subclasses of SuperHero:

• SpiderMan: This is a blueprint for Spider-Man
• AntMan: A blueprint for Ant-Man

So, each superhero becomes a subclass of SuperHero and a type in Swift. Each superhero is a blueprint that we will use to create instances. Suppose Kevin, Brandon, and Nicholas are three players that select a superhero as their preferred character to play a game in our app. Kevin and Brandon choose Spider-Man, and Nicholas selects Ant-Man. In our application, Kevin will be an instance of the SpiderMan subclass, Brandon will be an instance of the SpiderMan subclass, and Nicholas will be an instance of the AntMan subclass.

As Kevin, Brandon, and Nicholas are superheroes, they share many properties. Some of these properties will be initialized by the class, because the superhero they belong to determines some features—for example, the super powers, strength, running speed, flying speed (in case the superhero has flight abilities), attack power, and defense power. However, other properties will be specific to the instance, such as the name, weight, age, costume, and hair colors.