Original subtitles

0 In the last lesson, we've seen how we can create our classes and our objects using Dart. 1

But why do we actually need them anyways? 2

What purpose do they serve? 3

Well in order to understand this, we first have to understand how computers actually work. Behind the 4

metal shell and the pretty keyboard and the nice screen, 5

a computer is just composed of a large number of switches. And these switches can be in two states, on 6

or off. And it's through switching on and off many different switches 7

we end up telling the computer what it should do. 8

Now if you had to sit there and write all of these ones and zeros in order to program your computer, 9

you'd be there for years and in fact this is how people used to code way way back. 10

But then we thought that this is a bit painful because in order to just represent the letter A, 11

I have to write 01000001. And that is very painful and very time consuming. 12

This is what we would say is machine code. 13

So we came up with all sorts of ways of making it easier to write programs that sound and look more 14

like English so that we can actually interact with the computer without having to get down to the machine 15

level and start writing ones and zeros. 16

In the early days, a lot of the programming languages were what we would call procedural. 17

They would go from top to bottom/ So do this, then this then this then this then this, until forever basically. 18

And this is kind of easy to understand. But as your code gets more and more complex, then it gets a bit 19

hairy cause it's hard to know when something goes wrong, 20

what exactly went wrong? 21

Because you have to follow the logic from top to bottom and you have to really untangle it and you can 22

really shoot yourself in the foot quite easily. 23

So in a lot of places, complexity is always the enemy. 24

As humans we have pretty capable brains but we can only hold so much information in it at one time. The 25

more complex a program gets, the more likely it is that it will crash and it will have problems and it 26

won't perform very well. 27

So along came this concept of Object Oriented Programming, and a lot of people really loved the concept. 28

So languages that became really big such as Oracles, Java or Apple Swift or in fact Dart,which we're working 29

with, are all Object Oriented Programming languages. 30

So what does that mean? 31

Well it means that we're working with objects to do everything that our app or our program needs to 32

do. 33

And for those guys who are looking for a job as a software engineer, one of the most common questions 34

you get asked is 'What are the four pillars of Object Oriented Programming?' 35

What is Object Oriented Programming all about? And the four pillars 36

you'll very often hear people reel off are abstraction, encapsulation, inheritance and polymorphism. 37

Now it's a mouthful but very few people actually fully understand what these big words actually mean. 38

So I want to break it down and show you in the context of our app, why OOP is so great, and how does 39

it apply to Dart. 40

One of the first pillars is abstraction. 41

How can we make something that's complex into smaller pieces to make it more abstract? 42

Now if you've taken my courses before, you know how much I love food. 43

So in order to understand abstraction, we're going to talk about, you guessed it, food. 44

One of my favorite restaurants in Japan are these really tiny kind of hole-in-the-wall places where 45

there's only maybe four or five seats. But there's also just one guy who is the waiter, the chef, the cleaning 46

staff and he just does everything from behind the bar counter. When you make an order, you do it on a 47

vending machine and you give him the order. And then he'll cook you order he'll put it on the table for 48

you because it's so easy to reach. 49

And then once you're done he'll take your bowl and he'll put it in the dishwasher. 50

Now this is really cool but there are some limitations. He can't have more than say 10 customers right? 51

Because it will be complete nightmare to try and do all of those jobs himself. 52

And that's kind of the downside of that. 53

If we have a large piece of code that is trying to do many many things, then it's kind of like just having 54

one employee in your restaurant who's cooking, who's waiting on staff, who's taking payment at the cash register, 55

who's also taking reservations and bookings. And firstly, good luck finding somebody with the CV that can 56

do all of those things. 57

And if you hire them, you're going to completely destroy them because one person shouldn't have to do 58

so many things. 59

And if they did, then you end up having a limitation in how many customers you can serve or how big your 60

restaurant can be or how complex your app or program can be. 61

So as your program gets more complex and more interesting, then what you want to do is you want a modular 62

rise. 63

You want to make it more abstract and separate out different jobs. So you'll have the waiter who actually 64

brings the food to the customers. 65

You'll have the pastry chef who makes the cakes. You'll have the sous-chef and the chef who does the 66

rest of the cooking. 67

And now, what it means is that everybody has their own jobs. 68

They all know what they need to do and they don't get into each other's way and they don't have to all 69

do too much at once. 70

And now, you can expand your restaurant. You can serve more people and you can do more interesting things 71

with more abstraction. 72

So if you were creating a program, instead of creating a single large component which is capable of everything 73

it's all knowing and all doing, that kind of tends to end up in what we call spaghetti code where everything 74

is intermingled with each other. 75

And it's a mess to try and debug when something goes wrong or when something doesn't do what you expect 76

it to. 77

Instead it's much better to split out functionality into different components: the chef component, the 78

waiter component, the receptionist and the pastry chef. 79

And this is what abstraction is all about, being able to build more complex systems by creating smaller 80

pieces that have a defined job or defined role so that you can actually manage the complexity. 81

What does that actually mean when we try to apply it to our code? 82

Well at the moment, if you look inside our main.dart, you can see that it's getting pretty long right? 83

And it's trying to do a lot of things. 84

For example it has the questions of our question bank, 85

it tries to track which question we're on at the moment, when we need to get a new question we have to 86

look into our question bank. 87

And it also does things such as putting on the layout for our app, and just you know being able to implement 88

the buttons and all of that functionality. And it's getting a bit messy in here. 89

If our app got any more complex, then you might start getting a bit confused about exactly what does 90

what 91

in this main.dart file. 92

So let's abstract it. Let's make it more modular. In order to do that, 93

we're going to go into our lib folder. We're going to right click and we're going to create a new Dart file. 94

And we gonna call this Dart file quiz_brain because this is going to be the brains of our quiz. 95

Now when I asked you if you want to add it to Git, go ahead and click 96

Yes. 97

And now we can create on new quiz_brain. 98

And of course it's going to be a class. 99

So we're going to create a class called Quiz brain. So remember classes have to start out with capitals. 100

And in this class, we're going to define all of the things that a quiz should be and should be able to 101

do. 102

First of all, our quiz needs to have some questions. 103

Let's head into our main.dart, 104

and instead of having our question bank mixed in with all of the rest of the functionality, let's go 105

ahead and cut it out of here and put it into where it should be inside our quiz_brain. 106

The first thing you'll see is we have some errors here. 107

It doesn't know what this question thing is. 108

Well it's because we haven't actually yet imported our question.dart file which is where that class 109

Question is defined now. 110

While we're on the topic of our question file, the first thing to note is that at the moment, this class 111

is doing a very very simple job. 112

It defines the structure of every question namely that it should have a question and it should have 113

an answer. When we're creating the constructor for our question class, 114

we have named parameters here. 115

So in order to create a new question object, we have to write question newQuestion let's call it equals 116

a new question. 117

And we have to specify that q and also the a. 118

Now this is a bit wordy. Given that every question just has a text which is a piece of string and an 119

answer which is a boolean, 120

it's pretty straightforward to be able to see that if we create a question that has a string. 121

This is the text and then it has a boolean, 122

this is the answer. 123

It's not completely necessary to have the parameter names q and a in there, but this is your judgment 124

as well. 125

So if you prefer it the other way, keep it the other way. 126

But I find that this is much easier to read once we start building up a large bank of questions. 127

Speaking of a large bank of questions, it's not much of a quiz app with just three questions 128

right? 129

So if you open up your readme file, you'll notice that we've already included some pre typed questions. 130

There's 13 of them. 131

And if you copy everything between the back ticks, all of those questions, you can paste it and replace 132

what you have in your question bank at the moment. And they're already formatted so that we create a 133

new question object with a question text and an answer. Now all we have to do is to go into our main 134

.dart file and fix the errors that we have here. Because we deleted our question bank from our main 135

.dart file, 136

this no longer exists 137

and it tells you as much. But how can we refer to our quiz_brain? 138

Well we have to create a new quiz brain object. So first we have to go ahead and import our quiz_brain 139

.dart, 140

so let's put that in there. 141

And now we're able to create a new quiz brain object which is going to be called quizBrain. 142

And notice that when we name objects, they start out with a lowercase and we're going to set it to equal 143

a new quiz brain object. 144

So that constructs a new object which we can now tap into by referring to quizBrain. Down here where 145

we have our question bank, instead of using just the question bank which should exist locally, 146

we're going to write quizBrain.questionBank, because our question bank is now a property of our 147

quiz brain object. And it's right here. It's a list of questions. Now we no longer need to know about questions 148

in our main.dart file and we can delete this unused import. Notice that every time you stop requiring 149

some code in an import, it'll tell you by making it gray and giving it a squiggly line. 150

So let's delete that and we now need to only know about quiz brain inside our main.dart. 151

Now we've still got a few more errors down here. 152

So my challenge to you is to try and fix everything and run it to make sure that it still works in the 153

same way. 154

Pause the video and give that a go. All right. 155

So down her, we're going to do exactly the same as what we did before. Because our question bank is now 156

a property of our quiz brain, 157

we have to use the dot notation instead. 158

We have the write quizBrain.questionBank. And similarly down here, we have to write quizBrain. 159

questionBank, so that we're actually tapping into the actual question 160

bank. Now even though we had to add a little bit more code in our main.dart, at least our question 161

bank which is now pretty massive, is separated into a separate class. And this now abstracts some of the 162

functionality namely the brain for our quiz, into a separate object. 163

And now we've abstracted our code just a little bit more. And the other benefit is that say if we were 164

to create a different quiz, if we were to create a sports quiz for example, we don't have to change anything 165

about our main.dart. 166

We just have to provide a new file, say a sport quiz brain and everything in here will still work the 167

same. 168

And we just have to change the class that we're using to construct the quiz brain. 169

So you could have a quiz that has lots of different types of quiz brain, sports and news and general 170

knowledge and every time you want to switch between one to the other, you just change the object that 171

you're actually using for the current quiz. 172

So we've made our code base more reusable more modular and we've separated different jobs into different 173

classes. 174

Now if we run our app you can see that we now have more questions, 13 to be precise. 175

But here's a problem. In our quiz app, 176

let's say that we really hate losing. 177

Well we can actually change the answer to our questions. 178

So for example here we're trying to get the correct answer by tapping into our quiz brain, looking at 179

the question bank property and picking out the current question out of the question bank, then tapping 180

into the answer. 181

And this is what we would call getting. We're getting the value of that correct answer. 182

But equally I can also change it. 183

I can simply write quiz brain question bank current answer and I can set it to a new value. I can set 184

it to whatever it is that I picked, which in this case would be true 185

right? 186

Well if this happens before I check my answer, then if we hit save and we take a look at the actual correct 187

answers and what I get as a result here, you can see that we're on this question about the loudest sound 188

produced by an animal and the correct answer should be false. 189

But I'm going to press true anyways and it tells me that I got it right. 190

So how is it possible? I shouldn't be able to just change that, even if I want to be right all the time. 191

This is not very safe for our app. 192

Let's comment that out, and in the next lesson we're going to learn how we can make our code a bit better 193

and conform with the second pillar of OOP, which is encapsulation. 194

So for all of that and more, I'll see you on the next lesson.