Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Like classes, protocols can inherit from other protocols. But where classes are limited to a single superclass, protocols can inherit from many different protocols. This lets you create complex protocol requirements for use in your apps.
-
0:00
[MUSIC]
-
0:04
Before we jump into an exploration of protocols in the swift language,
-
0:08
let's clear up some confusion, as you just learned creating objects through
-
0:12
composition that is using different protocols to implement functionality.
-
0:17
Offer us is certain level of flexibility that inheritance doesn't,
-
0:21
but it can be hard to determine when we need composition vs inheritance,
-
0:26
a simple way to think about this is to ask if the relationship between the objects,
-
0:31
is in is a or has a relationship?
-
0:35
I found a good analogy online that I'll use here.
-
0:38
Let's say we have a base class called Airplane that modeled an airplane.
-
0:43
Now we want to model a Jetplane.
-
0:46
Well, a Jetplane is a type of Airplane.
-
0:49
So in this case,
-
0:50
since it's an IS-A relationship, Jetplane inherits from the Airplane.
-
0:56
When we have an IS-A type of relationship,
-
0:59
inheritance is best suited as our design pattern.
-
1:03
If a class wants to model the exact same behavior and
-
1:06
attributes of another class and perhaps add to it, then we use inheritance.
-
1:11
In the example a Jetplane, will do everything an Airplane can,
-
1:15
plus some more cool stuff, so we use inheritance.
-
1:19
On the flip side, if you only want to model a particular aspect,
-
1:23
a limited subset of this behavior then we use composition.
-
1:28
Let's say we're modeling a Bird.
-
1:30
Well a Bird is not an Airplane, but
-
1:32
it has a feature that the Airplane does as well they can both fly.
-
1:37
And it HAS-A a relationship, it makes sense to extract that common behavior out,
-
1:43
and create a specific protocol for it.
-
1:45
So in this case, we can create a Fly protocol that both the Airplane and
-
1:49
Bird can conform to.
-
1:51
There's another aspect of protocols that makes them more useful,
-
1:55
when it comes to constructing our object hierarchies, and
-
1:58
that is protocols can inherit from other protocols.
-
2:01
So, let's take a look at some examples.
-
2:04
When you come in here, we'll say Protocol Inheritance
-
2:09
in the IOSSCK certain classes have a property called description,
-
2:13
calling description returns a string representation of the object.
-
2:17
So let's create a protocol to do this, we'll call our protocol Printable, and
-
2:23
it has a single requirement, types that conform require that you implement
-
2:29
a description function that returns a string.
-
2:34
Okay, so up at the top over here, we should have a user model right over here.
-
2:42
We're going to comment this out.
-
2:46
Just so that we can rewrite this below.
-
2:51
All right now at the bottom here, let's create this user struct again.
-
2:58
So I'll say struct user.
-
3:01
We'll give it a name, An age, and an address.
-
3:09
Now during my development process, I'd like to inspect my objects at different
-
3:13
points, and I may printout these values of the properties to the console.
-
3:18
By conforming to printable and
-
3:20
implementing a description function, it's far easier for me to get a representation
-
3:25
of the object rather than individually writing out print statements.
-
3:29
So user can conform to printable, and
-
3:34
in the description function, we'll say return.
-
3:37
Name.
-
3:42
Age and address.
-
3:50
So now if we were to go ahead and create an instance.
-
3:56
Let's give it a few dummy values, so 28 and some address,
-
4:00
then instead of writing out a print statement to inspect each value, I can
-
4:06
say user dot description, and you'll see that I get that description string back.
-
4:12
Now this works but I also want a text representation,
-
4:16
that's formatted nicely, and a lot more readable.
-
4:18
So here we do have the stored properties printed out, but
-
4:22
I don't know which one is which really and if this is a complex class,
-
4:25
there'd be a lot of information, we could modify the description function over here.
-
4:31
But I don't want to, because sometimes, I may not want this formatted description.
-
4:37
The description string as we have it right now could be useful on its own.
-
4:41
So what I can do instead up over here, is I can create another protocol.
-
4:46
So we'll say protocol Prettyprintable and this is going to inherit from Printable.
-
4:56
Now inside PrettyPrintable,
-
4:58
I'm going to add a new requirement we want a prettyDescription function.
-
5:03
So this is one that's formatted.
-
5:06
Okay now, instead of having user conform to Printable,
-
5:09
we'll have it conform to prettyPrintable.
-
5:12
And inside I need to provide an implementation for the pretty description
-
5:16
function, and will do something simple say return the properties,
-
5:21
but again this time instead of just listing them all and will have.
-
5:25
Descriptions, surname returns a name property.
-
5:29
And then we'll do the newline character.
-
5:32
So right here, this backslash and n makes it print on a newline.
-
5:37
And then we'll print the age, and
-
5:40
I'm not putting a space here because I want it to start
-
5:45
immediately on the newline, So name, age, and and address.
-
5:51
So now down here we can call user dot prettyDescription,
-
5:55
and over here doesn't look great but if I were to put this in a print function, and
-
6:00
printed to the console, you'll see that it looks much better.
-
6:03
So we have name, age, and address each on an individual line.
-
6:07
Now this is good and
-
6:09
user conforming to prettyPrintable returns the string that we want.
-
6:13
So let's get rid of description altogether.
-
6:16
If you do that though you'll get an error, and if we check the error
-
6:21
it says that type of user now does not conform to the protocol printable.
-
6:26
Why is that happening?
-
6:27
Because we are conforming only to pretty printable.
-
6:30
Well when you inherit, using protocol inheritance anything that conforms to
-
6:35
prettyPintable, must also satisfy the requirements of Printable first,
-
6:40
and then any additional requirements enforced by prettyPrintable.
-
6:44
So here we have a single protocol,
-
6:47
that inherits the requirements of a protocol that's defined separately.
-
6:51
The neat thing though,
-
6:53
is that unlike classes protocol skin inherit from many other protocols.
-
6:59
If I wanted to define something else, like let's say a protocol not so
-
7:03
prettyPrintable obviously this doesn't make sense.
-
7:08
Let's say this inherits from Printable, or not even right
-
7:13
let's just make it a standalone protocol, and here will also have a not so pretty.
-
7:23
Now, prettyPrintable can inherit from Printable and notSoPrettyPrintable.
-
7:29
In this way, we can build up protocols to create a larger set of requirements.
-
7:34
Again, unlike classes which can only inherit from a single base class,
-
7:38
protocols can inherit from multiple protocols.
-
7:41
This is a very useful feature of protocols, and
-
7:43
in fact it's how the language itself is organized.
-
7:46
So, while this doesn't make sense, let's go to a real example
-
7:50
to see how multiple inheritance in protocols is used to great effect.
You need to sign up for Treehouse in order to download course files.
Sign up