Leave a rating/review
Notes: 37. Introduction
Update Notes: This course was originally recorded in 2019. It has been reviewed and all content and materials updated as of October 2021.
As we’ve been writing named types in these Swift courses, whether they’re structures, classes, or enumerations, we’ve basically had to write them from scratch every time. What if you need two types that are similar, but not exactly the same?
What if you want a category of types that you are sure have some property or method, but otherwise don’t need to be the same? Swift has two possible solutions for those problems. Two ways to make promises about a type’s properties or functionalities.
First, if you’re using classes, you can use class inheritance. This is also commonly called subclassing. With class inheritance, a class can get properties, methods, and even initializers from another, existing class.
The second option is to use Protocols! Protocols define a set of requirements that a type must meet. You might think of a protocol like a certification or stamp that says “This type is certified CaseIterable!” or “This type is approved to represent a View!”.
A protocol can be adopted by any named type, including other protocols, as long as they meet the requirements of that protocol.
In this part of the course, we’ll explore both class inheritance and protocols. We’ll see how they affect things like properties, methods, and initializers.
We’ll also take a little time to learn about extensions: a way to add functionality to types outside of their original definition, including types you didn’t write! But, first up, let’s take a look at class inheritance.