Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.5 Polymorphism

While inheritance is important in OOP, the ability to override the functionality in those base classes is important as well. In this lesson we will cover the basics of polymorphism and our ability to take advantage of it in the Swift programming language.

3.5 Polymorphism

Now that we understand the basics of inheritance in the realm of the Swift programming language, the next logical step to take within the object oriented programming paradigm is to jump into something called polymorphism. Now polymorphism can sometimes carry with it a shroud of mystery but I assure you that it truly is not a very complicated topic. All polymorphism means is that I can override some sort of existing functionality that was predefined in one of the types or classes that I have ultimately inherited from somewhere in my inheritance chain. So for example, I could say that yes, a manager inherits from employee, so this manager type does contain a doWork method and a jobFunction property as well as the first name and last name properties. Now, I would venture to say that in a normal work environment, a manager does have to dowork, but the work that a manager does is probably gonna be different from an, a typical employee, and so in this case, maybe a developer. So we can start to redefine what these operations in terms of functions and properties are within these classes to override them from previous levels of inheritance, so let's see how that works. So it's quite simple actually. So, I can go into my manager class. And actually just to prove a point, so I'm simply going to create a new instance of a manager and I'm going to say that manager is going to have a first name of Derek and a last name of Jensen. And at this point I can now reference my manager object and I say do work and as you can see here it's going to say that I am doing, or I am doing my work. But a manager's work is going to be different from an employee's work, so lets go ahead and redefine or override this doWork method. So in this case, you're simply going to use the override keyword, and in this case, this is a function. We're overriding a function here, and this function is actually do works. We're gonna override doWork, and we need to make sure that we specify everything the same as it is in the original implementation. So the signature or function type needs to be the same, it has to have the same name, the same inputs and the same output. So, at this point now I want to override this and I'm going to return, I'm doing my manager work. So, now that I've changed that, you can now see down below where I execute the doWork method, I am now seeing I am doing my manager work. So as you can see, I am actually changing the existing implementation of a previously defined inherited type to do what it is that is necessary at that particular level. So, that's kind of nice, but at the same time I can simply create an employee, so we'll save our employee is equal to an employee, and in this case it will be John Doe. And if I were to say that I want John Doe to doWork, John Doe is simply going to say that, I am doing my work. So now you have that separation that different levels in the inheritance chain are able to execute different pre-defined methods, or functions in this case, differently. But we're not limited to just functions here, we can override properties as well. And that's going to take the same form that we've just done, we say override and this is actually going to be a property and we're going to override in this case the job function property. So I'm going to paste this in here. I want to override our job function. But in this case, I don't want it to be the same as developer, its job function is going to be manager. So at this point, now when I go into my manager, I can now specify or take a look at its jobFunction, and as you can see here, we're getting a bit of an issue, and we have an ambiguous use of jobFunction. The problem that we're running into here is that I can't override an existing property with, with another stored property. If I want to override it, then I actually have to specify it as a computed property. So the way that we do that, if you recall, is by set, by creating getters and setters. So in this case, I'm simply going to override this with a, with a computed property. And when I'm doing this, once again, if you recall, I have to create a getter with the get keyword and a setter with the set keyword. And we're gonna say that this is going to have a variable name of new value. And we already know that this is going to be of string type so I don't have to specify any types or anything there. And if you don't recall the ins and outs of computer properties and getters and setters you can go back and take a look at the properties lesson earlier in the course. So at this point, I could do any sort of complicated logic that I want here but there's really not a whole lot extra that I really want to do. I actually just want to return that the jobFunction is now going to be manager, so that's gonna be fine. And then, let's say I want to set this, so somebody wants to actually set this jobFunction to something else. So how am I going to do that? Well there's an interesting little trick that you can use here, if I am in my manager class and I want to access some sort of functionality that is in the class that it's inheriting from you can refer to that as the superclass. So if I wanted to refer to the value that's stored in the superclass level, I could say super dot, and at this case it knows that the super of this particular class is employee, which has a doWork, firstName, lastName and jobFunction. And so I want to set the jobFunction equal to whatever new value is being passed in. Well that's good, but the problem now becomes if I set the jobFunction at the Manager level, it's going to change what's been defined at the Employee level, but we're just returning this hard-coded value here for its job function. So if I were to look at this now, you'll see that it's a manager, but if I were to specify that its jobFunction is equal to sleep, not to imply that managers sleep. Now if I were to access jobFunction a, again I would expect it to be manager, but in this case it is sleep. So the problem here is that I'm only returning a hard-coded value. So to retrieve the value that's in the superclass, once again I can simply say I want to return super dot jobFunction, and once I do that, you can see that I can now set my jobFunction property to be sleep, and then when I access it later on it's going to be sleep. So as you can see here now, we have the basics of the ability to implement polymorphism within our inheritance chain amongst the custom types that we're creating through classes, and be able to override functionality at certain levels that are necessary, and get access to the inherited types or the super types throughout our inheritance chain. So these are some very nice tricks to be able to have in your tool belt when you're doing object oriented programming.

Back to the top