Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Implementing the Productivity System
00:00
Everything regarding the PayrollSystem is working, but that’s not the only goal of this program. This program should also be able to track employee productivity. To do that, we’re going to add a new system to the program: a productivity system.
00:17 The productivity system will track productivity based on employee roles. There are four different roles. Managers walk around yelling at people and telling them what to do.
00:29 They are salaried employees that make a lot of money, probably more than they deserve. Secretaries do all of the paperwork for the managers and they ensure that everything gets billed and paid on time.
00:43 They’re also salaried employees, but they make less money. Sales employees make lots of phone calls to sell products. They have a base salary, but they also get a commission for each sale.
00:57 Finally, we have factory workers. They manufacture the products for the company and they’re paid by the hour. With these new classes in mind, I think it’s time we move some of our existing code into a new file.
01:12
I don’t think that the current employee classes belong in the hr.py file anymore, so let’s create a new Python file called employees and move them there.
01:32 I will cut this, move files, and paste it.
01:38
Now, we have to go back to program.py and make sure that we import employees.
01:45
We also need to fix some references since we moved some classes out of hr.py and into employees.py.
01:57
Let’s run this program to make sure that everything still works. Great. We haven’t broken anything yet. I’m going to move back into employees.py.
02:09
Here, we can add four new classes, one for each type of worker. First, let’s create the Manager class. The manager is paid a salary, so it should inherit from SalaryEmployee.
02:24
We’re not going to declare an .__init__() method here. This will mean that the Manager class will inherit the .__init__() method from SalaryEmployee implicitly, meaning that when we create a Manager object, we’ll need to pass in an id, a name, and a weekly_salary.
02:42
Instead, we’re going to implement a new method called .work(), which will take in the number of hours this manager has worked for. Then, it will print something like this: f'{self.name} screams and yells for {hours} hours.' We can access the .name instance attribute because this Manager class has inherited all of the attributes from the SalaryEmployee.
03:13
If we had defined an empty .__init__() method here, one that did not call the .__init__() method of SalaryEmployee, then we would not have access to this .name attribute. I’ll do the same thing for the next three classes, making sure that Secretary inherits from SalaryEmployee, SalesPerson inherits from CommissionEmployee, and FactoryWorker inherits from HourlyEmployee.
03:41
Now, all that’s left to do is create the productivity system that will use these classes. I’ll do that in a new Python file called productivity.py.
03:55
I’ll create a new class called ProductivitySystem that will be similar to the PayrollSystem that we created earlier. This class will have a single method called .track() that will take in a collection of employees and the number of hours they all should work for.
04:15
Then, it will print out a heading to be displayed in the standard output, and then it will iterate through each employee in our collection of employees, calling the .work() method on each employee and passing in the number of hours as an argument. Finally, I’ll just print a space (' ') so things are nice and separated in the standard output.
04:41
This ProductivitySystem requires that each Employee object have a .work() method—that’s the interface that the employees must conform to.
04:52
Let’s move back into program.py and create the required objects to use our new ProductivitySystem. First, I’m going to import the productivity module.
05:06 Then, I’ll change these class references so that we instantiate the new classes that we just created. Remember, I’m replacing each one of these classes with one of its child classes, which it inherits everything from, so things should still work.
05:26 I’m also going to rename these variables.
05:40
Finally, I will create a new ProductivitySystem object, just like we normally would. I’ll call its .track() method, passing in our list of employees and the number 40, which means work 40 hours.
05:58
This will all happen before the PayrollSystem runs.
06:06
I will run this program and you can see that everyone is doing the appropriate job and the PayrollSystem still calculates correctly. This is all fine and dandy, but take a look at our new UML diagram.
06:23
We added four new classes that inherit from existing classes and implement a new interface called IWorker. A class that conforms to IWorker is one that can be tracked using the ProductivitySystem. As you can see, things are starting to get pretty messy. If requirements change or we need to add new features, then the number of classes we create might start growing exponentially.
06:53 This is called the class explosion problem, and in the next video, you’ll learn about multiple inheritance, which we can use to clean this mess up.
Austin Cepalia RP Team on May 15, 2020
@rafaelsalomon No. If that’s how it is coming off, then that was not my intention.
henriqueluc4s on Aug. 16, 2020
@rafaelsalomon well, you can change it. “Manager” is a woman, the “Factory Worker” is a cross gender and the “Secretary” is actually a guy hired yesterday.
Ariba S on June 6, 2024
just noted an erorr with the Productivity System. The Factory worker is an hourly employee, and we assign number of hours worked when we initialise it. Yet, in the productivity system instance, we give a general number of hours worked for everybody. It doesn’t match the factory workers hours worked.
Become a Member to join the conversation.
rafaelsalomon on May 15, 2020
Is it possible that there’s some gender bias in the naming of the fictional workers. The “Manager” is a guy. The “Factory Worker” is a guy. And the “Secretary” is a woman.