[MUSIC]

Before we jump into an exploration of protocols in the swift language,

let's clear up some confusion, as you just learned creating objects through

composition that is using different protocols to implement functionality.

Offer us is certain level of flexibility that inheritance doesn't,

but it can be hard to determine when we need composition vs inheritance,

a simple way to think about this is to ask if the relationship between the objects,

is in is a or has a relationship?

I found a good analogy online that I'll use here.

Let's say we have a base class called Airplane that modeled an airplane.

Now we want to model a Jetplane.

Well, a Jetplane is a type of Airplane.

So in this case,

since it's an IS-A relationship, Jetplane inherits from the Airplane.

When we have an IS-A type of relationship,

inheritance is best suited as our design pattern.

If a class wants to model the exact same behavior and

attributes of another class and perhaps add to it, then we use inheritance.

In the example a Jetplane, will do everything an Airplane can,

plus some more cool stuff, so we use inheritance.

On the flip side, if you only want to model a particular aspect,

a limited subset of this behavior then we use composition.

Let's say we're modeling a Bird.

Well a Bird is not an Airplane, but

it has a feature that the Airplane does as well they can both fly.

And it HAS-A a relationship, it makes sense to extract that common behavior out,

and create a specific protocol for it.

So in this case, we can create a Fly protocol that both the Airplane and

Bird can conform to.

There's another aspect of protocols that makes them more useful,

when it comes to constructing our object hierarchies, and

that is protocols can inherit from other protocols.

So, let's take a look at some examples.

When you come in here, we'll say Protocol Inheritance

in the IOSSCK certain classes have a property called description,

calling description returns a string representation of the object.

So let's create a protocol to do this, we'll call our protocol Printable, and

it has a single requirement, types that conform require that you implement

a description function that returns a string.

Okay, so up at the top over here, we should have a user model right over here.

We're going to comment this out.

Just so that we can rewrite this below.

All right now at the bottom here, let's create this user struct again.

So I'll say struct user.

We'll give it a name, An age, and an address.

Now during my development process, I'd like to inspect my objects at different

points, and I may printout these values of the properties to the console.

By conforming to printable and

implementing a description function, it's far easier for me to get a representation

of the object rather than individually writing out print statements.

So user can conform to printable, and

in the description function, we'll say return.

Name.

Age and address.

So now if we were to go ahead and create an instance.

Let's give it a few dummy values, so 28 and some address,

then instead of writing out a print statement to inspect each value, I can

say user dot description, and you'll see that I get that description string back.

Now this works but I also want a text representation,

that's formatted nicely, and a lot more readable.

So here we do have the stored properties printed out, but

I don't know which one is which really and if this is a complex class,

there'd be a lot of information, we could modify the description function over here.

But I don't want to, because sometimes, I may not want this formatted description.

The description string as we have it right now could be useful on its own.

So what I can do instead up over here, is I can create another protocol.

So we'll say protocol Prettyprintable and this is going to inherit from Printable.

Now inside PrettyPrintable,

I'm going to add a new requirement we want a prettyDescription function.

So this is one that's formatted.

Okay now, instead of having user conform to Printable,

we'll have it conform to prettyPrintable.

And inside I need to provide an implementation for the pretty description

function, and will do something simple say return the properties,

but again this time instead of just listing them all and will have.

Descriptions, surname returns a name property.

And then we'll do the newline character.

So right here, this backslash and n makes it print on a newline.

And then we'll print the age, and

I'm not putting a space here because I want it to start

immediately on the newline, So name, age, and and address.

So now down here we can call user dot prettyDescription,

and over here doesn't look great but if I were to put this in a print function, and

printed to the console, you'll see that it looks much better.

So we have name, age, and address each on an individual line.

Now this is good and

user conforming to prettyPrintable returns the string that we want.

So let's get rid of description altogether.

If you do that though you'll get an error, and if we check the error

it says that type of user now does not conform to the protocol printable.

Why is that happening?

Because we are conforming only to pretty printable.

Well when you inherit, using protocol inheritance anything that conforms to

prettyPintable, must also satisfy the requirements of Printable first,

and then any additional requirements enforced by prettyPrintable.

So here we have a single protocol,

that inherits the requirements of a protocol that's defined separately.

The neat thing though,

is that unlike classes protocol skin inherit from many other protocols.

If I wanted to define something else, like let's say a protocol not so

prettyPrintable obviously this doesn't make sense.

Let's say this inherits from Printable, or not even right

let's just make it a standalone protocol, and here will also have a not so pretty.

Now, prettyPrintable can inherit from Printable and notSoPrettyPrintable.

In this way, we can build up protocols to create a larger set of requirements.

Again, unlike classes which can only inherit from a single base class,

protocols can inherit from multiple protocols.

This is a very useful feature of protocols, and

in fact it's how the language itself is organized.

So, while this doesn't make sense, let's go to a real example

to see how multiple inheritance in protocols is used to great effect.