We now know the basic syntax of protocols, but why are they useful?

Let's take a look at a scenario.

Now bear with me, this is going to be a bit of a longer example.

So we'll have more code than usual to write.

Here we're going to define another hypothetical piece of softwar,

an employee database for a particular company.

So what could the employee class look like?

So let's do something like this, import Foundation.

I'm going to define an enum EmployeeType.

This isn't necessary, but it'll make our example a bit cleaner.

So we have managers and traditional.

And then our Employee class

is going to define some basic properties, some basic attributes about an employee.

So we'll have a name, We'll have an address,

A startDate, What type of employee they are,

so EmployeeType, And then we'll have an initializer.

So init with name, address.

We'll just make this easy and

give the exact stored property values through the initializer.

A startDate, And a type.

Okay, self.name = name, self.address = address.

If anything, this is good practice as to how you create an initializer and

set up stored properties.

And then type.

And let's say we're going to use this software to pay our employees.

So we need to implement a method to calculate a particular employee's wages.

Now here's where things can start to get hairy.

In most companies, there are different types of employees.

Let's assume, in our example, we have two types, hourly employees and

salaried employees.

How would we model this?

Now since hourly and salaried employees both have a lot of information in common,

information that we've already modeled in the Employee class,

we can create two classes, hourly employee and

salaried employee, that are subclasses of the Employee class.

So they'd look something like this, class HourlyEmployee.

This inherits from Employee.

And then it adds information about hourlyWage.

And to make this example easier and not have to define initializers,

we'll just give these default values.

hoursWorked, for now we'll just put as 0.

And vacation time.

I don't really need these, so let's get rid of those.

Okay, so this is what HourlyEmployee looks like.

It has everything Employee has plus some additional information about

how long they worked.

What about salaried?

So class SalariedEmployee, Also inherits from Employee.

And then we're going to add some information, again, a default value.

We'll say this is random 50000.00.

Then benefits, These are purely arbitrary.

Deductions, And

some vacation time.

Let's make another assumption about this software while we're at it.

Payroll is handled by a separate component in this app.

When calculating the pay for a particular employee,

a pay method is called on an instance of an employee class.

We don't have a payroll app modeled, of course.

But we can assume it would look something like this.

We would have a pay function that takes an Employee instance.

And then does something with it.

We're going to issue a paycheck by calling some pay method on

each of these employees.

Every time we call pay, regardless of whether it was a salaried employee or

hourly, we expect a certain result back.

Let's say we want information about the base pay, benefits, vacation, and

any deductions.

Now we also need to guarantee that our subclasses contain this

pay method that returns this information.

And that both of them return the same type.

Because we just want to call pay on an Employee.

We don't want to worry about what type of employee this is and so on.

So how do we do this?

One way is we could define the pay method in the base class,

Employee, so that both subclasses inherit it.

So let's try that.

Before we implement a pay function in the Employee class,

let's create a very simple struct to represent a paycheck of sorts.

So struct Paycheck.

And this will have information about the base pay, any benefits,

Any deductions, and vacation time.

So now we can go back to Employee and define a pay function,

That will return a paycheck every time it's called.

Unfortunately, in the Employee class,

we don't have any of the information we need to calculate pay.

So we just need to return placeholder values for now.

So we'll say return Paycheck.

And then using that initializer, it will just pass in 0 for all the values.

Now this is already starting to look bad.

Because we have a method here, pay, that returns incorrect information.

Well, let's ignore that for now.

But now, in pay, when we get an Employee, so when we call the pay method,

we can then go ahead and call that pay function on each employee to pay them.

Okay, but we still don't have any accurate information, right?

If I were to call pay, even if it were an instance of HourlyEmployee or Salaried,

it would revert to calling pay on the base class, which returns 0.

What we need to do is go into each subclass and then override the pay method.

And use specific information that each class provides to calculate wages.

So for example, I can override pay in HourlyEmployee.

I can calculate their base pay by doing the hourlyWage * hoursWorked.

And then I'll return a paycheck instance with the base pay.

And for the sake of the example, 0 for everything else.

So this needs to be 0.0.

Because we have an error since they're incompatible types, okay?

And now this seems to work.

Let's not worry about SalariedEmployee just yet.

But let's look into the future.

The company has grown and hourly employees are further broken down into two

categories, part-time and full-time.

Now we have to override the pay method again in each of these subclasses.

And make sure we're doing the right thing.

This is far from the ideal solution.

By requiring us to override a method to implement the correct functionality,

we've made a room for some bad bugs.

The big thing is what if I forget to override the pay method

in the HourlyEmployee class?

Now if I call pay on an instance, the method in the parent class is executed.

And this returns useless values.

For example, let's assume that I'd forgotten here to implement pay for

the SalariedEmployee.

And if I passed in an instance of the SalariedEmployee to the pay function,

I'm going to get a paycheck of 0.

If this were a real app and this bug goes unnoticed, because we're not doing

anything wrong that the compiler can identify and tell us,

we're going to send out a paycheck of $0 to all our hourly employees.

This is where some facets of inheritance start to breakdown.

In that they're not ideal for all use cases.

Yes, these classes are related in that they're all employees and

we reuse code and encapsulate data here by using inheritance.

But not all aspects of the classes are related.

Mind you, I'm not saying that inheritance is bad.

It just doesn't work here.

It may not be the right tool for this job, specifically.

Protocols, though, offer a different kind of solution.

Let's take a break here.

In the next video, we'll revisit this same problem using protocols.