Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
0 So we're on to our final pillar and that's polymorphism or changing shapes. 1
How does this work? 2
Let's say that we're abstracting our program and we're creating a separate module for separate roles. 3
And we're inheriting a lot of the behavior from parent classes. 4
But when we're doing a lot of inheritance, we know that we get basically a copy of what the parent class 5
is able to do. 6
So our electric car can drive and our electric car has the same properties. But we don't really want 7
to end up with just a whole bunch of clones in our program. That isn't great 8
right? 9
We want to be able to define customer behavior as well. 10
So in the case of our chef and our pastry chef, 11
well, there's probably similarities between those two roles. 12
They can probably both bake something in the oven and they can probably both make some sauce in a saucepan. 13
But they might go about those behaviors a little bit differently. 14
So maybe the pastry chef has to be a little bit more delicate with the things that he's working with, 15
and the chef maybe, 16
well she has to do things a little bit quicker because it's complete mayhem in the kitchen. 17
But the point is that when you are inheriting from a parent class, there are probably things that will 18
save yourself time that you don't have to recreate and you can simply inherit. 19
But some of those behaviors that you inheriting, some of the methods, you might want to customize it for 20
your own needs. 21
There's two ways that you can do this. 22
Continuing our car analogy, we might have simply a LevitatingCar, and this LevitatingCar is going to 23
inherit from our Car class. 24
So we're going to write extends the Car class, and this is because a levitating car probably also has 5 25
seats, then it probably also looks pretty much the same as a car. It might share the same properties 26
but a levitating car doesn't have wheels, at least in my mind. 27
And instead, if we were to implement the drive functionality of a levitating car, it would probably be 28
a little bit different. Because we're already inheriting from the Car class that has a drive method, if 29
we want to use the same method, we have to override it and to do that we use the @ sign to specify 30
that there's a very important word coming up, and the word is override. And then on the next line, we can 31
create our own version of drive so we can write void drive and it looks exactly the same as before. But 32
now, it's our own version of the drive method and our levitating car instead of moving wheels, 33
it's going to simply glide forwards, very classy. 34
So now when we create our levitating car, 35
and we call upon our levitating car, our MagLev to drive, then you can see that it should now glide forwards 36
instead of using its parents implementation of drive. So even though I inherit from my parents a number 37
of traits and a number of behaviors, there's also things that I do differently from them or I'd like 38
to think I do differently. 39
For example the way I use a computer, I might get to use a computer to program it whereas my parents 40
might just use it to go on Facebook. 41
But the point is we are now able to override a parent behavior and provide our own custom version of 42
it but we can actually go even further than that. 43
We can actually take some of the good parts from our parent class, but simply just add to it. 44
Let me show you what I mean. 45
Let's build a new class and this is going to be a self driving car. 46
And of course it's a car. 47
So it's going to extend the car class. 48
It's going to have a drive method and it's going to have 5 seats. So, easy. That was done. 49
But in addition to being able to drive and make the wheels turn, 50
I also want my self-driving car to be able to steer the car as well. Instead of simply just getting the 51
wheels to turn, 52
I'm going to get my self-driving car to drive me towards a destination. 53
So I'm going to create a new property called destination. And this destination is going to be set when 54
I create a new object from the self-driving car. 55
So I'm going to define a custom constructor, so self-driving car, when we create it, 56
we have to provide a destination. And we'll call that userSetDestination. 57
And then once we create our self-driving car, we'll set the destination property to equal the user set 58
destination that was provided when we created our new object. 59
Now inside this self-driving car, when we decide to drive it, we kind of want to inherit the functionality 60
of driving which is wheels moving, 61
and as a consequence the car moving. 62
But we want to add to it as well. We can again override our parent method code drive. 63
So it has to look exactly the same. 64
It's also void drive empty parentheses. 65
And then we're going to trigger the parent behavior by calling super, which stands for the superclass 66
or the parent.drive. 67
This is going to carry out the behavior of the superclass' drive method. 68
But then afterwards, we're going to do our own thing. We're going to say that the steering is going to 69
steer us towards the destination. 70
Here's how it would look when we actually call this method in our main. So we could create our new self 71
driving car, we'll call it myWaymo. And it's gonna be equal to a new self driving car. And when I create 72
myWaymo as a new self-driving car, I have to provide a destination. 73
So let's drive it towards 1 Hacker way. 74
And now when I say myWaymo.drive calling that drive method, 75
then when I hit run, you'll see two things happen. 76
One is that it'll carry out the parents version of drive, which is simply to print 'wheels turn', but it'll 77
also do its own thing which is steering towards the destination. 78
And this all comes from just calling that one drive method. 79
This is polymorphism in action. 80
We're able to inherit from our parents, but we're able to also improve on it. 81
We're able to change it be a little bit different by overriding their methods. And if we come back to 82
our Flutter code, you can see that we're doing that every time we're calling the build method. 83
So a stateless widget already has an implementation for the build method, but in our code, we override 84
it and we provide what it is that we want to do instead. 85
And this way, even though we're inheriting, we're able to be a little bit different and customize what 86
our stateless or our stateful widgets do. 87
So getting the best parts, but then also doing custom things using these inherited classes.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.