Hello, and welcome back. In this video, we'll take a look at Interfaces and conclude our look into classes and object oriented programming in the process. So, you can think of Interfaces as similar to abstract classes, this human class that we built in the last video. In that, there will be a template that you can incorporate in your classes and you can also inherit all the implemented methods and reuse them, but when thinking of Interfaces, think primarily of behaviors rather than properties. And along those lines, Interfaces cannot have constructors. You can also extend multiple interfaces in the same class. 

For example here, we have employee only being able to inherit from one abstract class over here, but employee could extend multiple Interfaces if that was necessary. Let's say I had two Interfaces. I'm going to go ahead and define them. I'll say, interface 'HumanActions' and I'll call another interface 'EmployeeActions,' okay? So, I have two interfaces defined over here, and this class Employee it could extend both of them if necessary. I'm going to make some space and move this to the next line. Along with inheriting from Human, we can say, 'HumanActions' and 'EmployeeActions', both of them if we want, okay?

And notice, because Interfaces don't have constructors, we don't need to put parentheses after their names, right? Like we had to do for classes when we were inheriting from them, because there's nothing to construct. So, let's go ahead and add some methods to our interfaces. I'll start with HumanActions and let's think of a couple of methods. Actually I'm going to put curly braces here. All right, so, HumanActions, I'll say, 'eat' and then, another one I'll say, 'walk.' And for Employees, I'm going to go  ahead  and add curly braces, work( ) and then takeVacation( ), right? Now, as I've added these methods which I haven't implemented in Interface, which again I can implement them here if I want to, but the expectation is, whoever is extending or using the Interface, that class is going to implement them if they're not already implemented. 

So, if I scroll down, you see Employee  is now showing an error and if I hover over it, you see that Employees is not abstract and does not implement abstract member and it lists out the members from these Interfaces that need to be implemented. And if I go ahead and define one of these, let's say, method eat( ) over here. If I go ahead and say, println( "I'm Human and I'm eating") and scroll down, this one will still have the error from the other members not being implemented, but no longer will it display eat( ), right? You see, it starts with walk( ) which is the second one right here. It doesn't complain about eat anymore because it's already been implemented. And notice also that, I didn't have to specify abstract or anything before the method names in order to indicate that they'll be implemented by whoever is extending these interfaces. And that's because that's default behavior for Interfaces. 

That's the expectation. So, basically I get the same behavior from these methods as I would have from abstract methods in abstract classes. So, I'm going to go ahead and add these members over here for my Employee class. If I go to More actions, you see Implement members and I'll implement walk( ) from HumanActions, there you go. And then, I'll add the other ones, Implement members, walk and takeVacation from employee actions. Now that they're there, the error goes away. Now, what if I wanted to override the eat method from HumanActions and implement my own in Employee? Let's say I want to do that. Well, I could do that. I would simply do what I'm doing for the other methods. I'd say, 'override fun eat( )' there you go. 

And this one by default, calls the super.eat( ). So, this eat method over here from HumanActions, but I can get rid of that if I want, right? I can say something like, 'println( "I'm eating but from the Employee class, not HumanActions"), all right? So, notice how for this to happen, I didn't have to declare this open or anything, right? Which I would have to do if I was inheriting from a class. So, let's go ahead and test this out. I'm going to go to my main( ), get rid of all this. Actually, I don't want to get rid of all that. I want to get rid of this, the Student, because I'm using Employee over here. So, I'll create John as an Employee, john.printDetails( ) is fine, but I'll also do John and you see  eat( ) shows up over there. Let's see what that does, Control+Shift+R, run it. It looks like I have a problem. 

So, I'm just going to try again. Last time, trying again worked. So, there you go, it worked this time as well, all right. So, there you go, John Doe from the previous video, and right here I'm eating but from the Employee class, not HumanActions, all right? Because it used the function eat( ) that was defined for employee, okay. So, that's how you'd create and work with Interfaces. And with that, we come to the conclusion of our look at classes and object oriented programming. Hope you found this structural look useful and I feel we're now ready to dive into Recycler Views and the next stage of our Android app development. And hopefully, going forward when we create objects or inherit from classes and create our own classes and objects and all that stuff, you'll find it easier and easier. All right, great, I'll see you in the next video.