Every subclass of employee needs to have a pay method.

This method also has to have a very specific return value.

We need to centrally enforce this design and we can do that using a protocol.

Let's define the protocol.

Earlier, when we define our first protocol, full nameable,

we specified that conforming types were required to implement a stored property.

With protocols,

we can require specific methods be implemented by conforming types as well.

These methods are written as part of the protocol's definition, in exactly

the same way as for normal methods but without curly braces or a method body.

So over here up at the top above paycheck,

let's define this protocol which will call payable and

define a single instance method requirement.

So we'll say then conforming types need to implement a function

named pay that takes no parameters, and returns a paycheck.

Now we can get rid of the method, the pay method, in our employee base class.

Since employee has no information to calculate pay,

we have a better encapsulation of data and behavior without that particular method.

It doesn't really serve a purpose in there.

Getting rid of this method introduces errors.

And that's because now in our only employee.

We're not overriding a method from our superclass.

So let's get rid of this entire method.

Now, to ensure that our classes always implement the pay method.

All we need to do is conform to the protocol.

Typically, we specify a protocol conformance by adding a colon to the types

name, and then listing the protocol.

But here we've already listed employee as the superclass.

Now to add any additional conformance, all we need to do is add a comma,

and then list the payable protocol as well.

In this way we can specify there are classes conform to multiple protocols.

But let's not get ahead of ourselves.

And this brings up at error and that's because hourly employee now

does not implement pay as required by the protocol.

So let's put that in there.

This is essentially the same as before.

So we type pay.

And it should auto complete because it knows that our type

is missing the pay method.

On the protocol conformance that we've listed in here again will calculate

base as the hours worked times the hourly wage.

And then will return an instance of pay check with the base pay and

then everything else set to zero.

Now we fulfilled our contract and can guarantee that we're implementing pain.

What about salaried employee though because a protocol states that

all you do is implement a method and doesn't care about the body of the method,

here we can provide a different implementation.

So again let's make salaried employee conform to payable and in

here will provide a completely different implementation for the pay method.

We'll say let monthly salary equal salary divided by 12.

And then we'll return paycheck with the base set to monthly.

And then we'll just pass through all the other values from the store properties.

Now we can call pay on either the salaried employee or

hourly employee and get an implementation that makes sense for each type.

Because protocols are fully fledged types like a class or

struct We can go and take this step further.

Now before we move on,

let's fix this error this is supposed to be a double val so that's 2.0.

Now because protocols are fully fledged types something we haven't discussed yet

but we will, like a class or struct they're a fully fledged type.

And because of that we can specify payable as the argument for

a function instead of employee over here.

So the problem now, you'll see,is that employee doesn't have a pay method.

Well, to make this easier we know that SalariedEmployee has a pay method.

So we could say SalariedEmployee and now we can call pay.

But what if we wanted to pass in an hourly employee here.

The nice thing is because peer is a type

we can specify the type of employee here is payable.

This guarantees that we can only pass in an instance of a class or

a time that conforms to the payable protocol.

This can be a bit tricky to understand at first.

You were saying that the instance passed in as an argument to pay

needs to conform to the payable protocol.

The instance can be of type hourly employee,

it can be salaried employee because both of them conform to payable.

But it also means that it can be any type that we create in the future

that conforms to payable.

We don't know anything about these types that are passed in, but

because the interface the blueprint that is exposed to us

tells us that they implement the pay method that's all we care about.

So all we want to do is call pay on each employee payable exposes that.

So what I mean makes poses?

If I create an instance of employee.

Let's say we make a base class right.

Employee and we'll provide some values so we'll say Pasan,

someAddress, The current date and I'm a traditionalEmployee.

And then if I tried to call pay and

pass through the employee this is not going to work.

Because employee the base class does not conform to the payable protocol and

you'll see that here.

Now this way you can see that we're guaranteed that will never call pay

on a class that doesn't implement it.

And because we can do that we don't have to have some

meaningless pay function in the base class that provides bogus values.

Now what if we were to change this from employee to salaried employee?

We can use that same initializer because it inherits it

you'll see that now it works.

So the interesting thing,

what I meant by exposed earlier is because when we pass in this instance through

all we know inside the function is that this employee conforms to payable.

This means that we can only call things that are listed in the payable protocol.

Now we know that we're passing in a salaried employee here.

And salaried employee has a name store property.

But inside here if I were to call employee.name, you'll see that it doesn't

know how to complete because, in the scope of this function, that doesn't exist.

The protocol is a blueprint.

And this blueprint says that all you know about this type is that it implements pay.

You'll get used to this and we'll talk more about this.

But to conclude this example, you'll see that if I change this to HourlyEmployee,

this works again as well because.

Oops, if I spell things right.

Hourly.

Because this type also conforms to payable.

By using protocols, we get the behavior we desire.

Without a lot of the tight fragile coupling

that was achieved by attempting this specific design through inheritance.

This type of structure where we designed a class through protocol conformance rather

than inheritance is called composition and is an extremely powerful tool

that helps build encapsulated loosely coupled models and code bases.

So this was point number one as to why protocols are useful.

When we have a set of closely related classes that implement methods

which define similar behavior but

have different implementations protocols lead to better code than inheritance.

So let me repeat that again.

When we have a set of closely related classes, as these two hour early and

salaried employee classes are, that implements methods which define

similar behavior, which in our case is the pay method, but

end up having different implementations, protocols lead to better code.

Because then we do not have to define

some placeholder type in the base class employee to get to work.

Now earlier we talked about how we could specify payable

as an argument to this function.

This is because in Swift protocols are also first class types on their own.

And in the next video will look a bit more at how this works.