Original subtitles

1 1

So this section 2

2

is about object-oriented programming, 3

3

and this lecture is gonna be 4

4

a very general, high level overview 5

5

of this programming paradigm. 6

6

So we're gonna talk about 7

7

what object-oriented programming is, 8

8

how it works in general, 9

9

and about its four fundamental principles. 10

10

So this is gonna be a really important 11

11

and valuable lecture. 12

12

And so let's get started. 13

13

So, first of all, what is object-oriented programming? 14

14

Well, object-oriented programming, 15

15

or OOP in short, 16

16

is a programming paradigm that is based 17

17

on the concept of objects. 18

18

And paradigm simply means 19

19

the style of the code, 20

20

so the how we write and organize code. 21

21

Now we use objects to model, 22

22

so to describe aspects of the real world, 23

23

like a user or a to-do list item, 24

24

or even more abstract features 25

25

like an HTML component 26

26

or some kind of data structure. 27

27

Now, as we already know, objects can contain data, 28

28

which we call properties, and also code, 29

29

which we call methods. 30

30

So we can say that by using objects, 31

31

we pack all the data 32

32

and the corresponding behavior 33

33

all into one big block. 34

34

So again, that's data and corresponding behavior. 35

35

And this makes it super easy 36

36

to act directly on the data. 37

37

And speaking of blocks, 38

38

that's exactly what objects are supposed to be. 39

39

So in OOP, which is the acronym 40

40

that I'm gonna use instead of object-oriented programming. 41

41

Okay. 42

42

So in OOP objects are self-contained pieces of code 43

43

or blocks of code, 44

44

like small applications on their own. 45

45

And we then use these objects 46

46

as building blocks of our applications 47

47

and make objects interact with one another. 48

48

Now these interactions happen 49

49

through a so-called public interface, 50

50

which we also call API. 51

51

This interface is basically a bunch of methods 52

52

that a code outside of the objects 53

53

can access and that we use to communicate 54

54

with the object. 55

55

Okay. 56

56

So let's take a breath here 57

57

because this all sounds kind of abstract, right? 58

58

But don't worry. 59

59

It will make more sense 60

60

once we start developing these concepts 61

61

using code throughout this section. 62

62

But anyway, why does OOP actually exist? 63

63

Well, this paradigm was developed 64

64

with the goal of organizing code, 65

65

so to make it more flexible 66

66

and easier to maintain. 67

67

So before OOP, we might have a bunch of codes 68

68

gathered across multiple functions, 69

69

or even in the global scope 70

70

without any structure. 71

71

And this particular like crazy style of code 72

72

is what we usually call spaghetti code 73

73

and spaghetti code makes it very hard 74

74

to maintain large code bases 75

75

and let alone, add new functionalities to it. 76

76

So the idea of OOP was basically created 77

77

as a solution to this problem. 78

78

And apparently it worked because today, 79

79

OOP is probably the most popular 80

80

and most widely used programming paradigm 81

81

in large scale software engineering. 82

82

Now, OOP is certainly not the only way 83

83

of writing organized and maintainable code. 84

84

So in fact, there're many other paradigms 85

85

that have become increasingly popular 86

86

and one of them is functional programming. 87

87

And functional programming allows us 88

88

to achieve the exact same goal 89

89

of basically avoiding spaghetti code. 90

90

And as I have been saying, 91

91

we will talk about functional programming 92

92

later in the course and compare it 93

93

with object-oriented programming. 94

94

But for now, let's focus on OOP. 95

95

Now, actually using objects 96

96

is nothing new for us at this point, right? 97

97

We have been using them all the time. 98

98

However, up until now, 99

99

we have basically only used objects 100

100

as loose collections of data 101

101

and without making them interact with one another. 102

102

Also, we didn't have a way 103

103

to generate objects programmatically. 104

104

All we ever did was using simple object literals, 105

105

but in OOP, we actually need a way to generate, 106

106

so to create, new objects from our code. 107

107

And to do that in traditional OOP, 108

108

we use something called classes. 109

109

You can think of a class as a blueprint, 110

110

which can then be used to create new objects 111

111

based on the rules described in the class. 112

112

So it's just like an architecture 113

113

where the architect develops a blueprint 114

114

to exactly plan and describe a house. 115

115

But the blueprint is really just an abstract plan, 116

116

like a set of rules, 117

117

but nothing tangible that you can actually touch. 118

118

However, from that blueprint, 119

119

many real houses can then be built 120

120

in the real world. 121

121

And with classes it's just the same. 122

122

So let's take a look at this fictional user class 123

123

as an example. 124

124

And I say fictional 125

125

because this is not actual JavaScript syntax. 126

126

Okay. 127

127

Because JavaScript does not actually support 128

128

real classes like I'm explaining here. 129

129

We do have a class syntax in JavaScript too, 130

130

but it still works a bit differently 131

131

from what I'm gonna show you here. 132

132

However, the idea of creating objects 133

133

from a kind of blueprint 134

134

is still a very useful mental model to have. 135

135

Because in general terms, 136

136

this is still how OOP works 137

137

across all languages 138

138

and that includes JavaScript. 139

139

And so that's the reason 140

140

why I'm showing you this here, 141

141

so as a conceptual overview, 142

142

and for you to have this as a mental model. 143

143

But anyway, back to our fictional class here, 144

144

we can see that it kind of describes a user 145

145

who has a username, a password, and an email. 146

146

So it's a description of data about a user, 147

147

but it's not the data itself yet. 148

148

Because remember, the class is really just a plan 149

149

and a plan doesn't contain the real world data just yet. 150

150

On the other hand, we then have the behavior 151

151

that is associated with the data. 152

152

And in this case, 153

153

that's just a login method 154

154

and a method to send messages. 155

155

So just like we learned in the last slide, 156

156

this class has everything related to a user. 157

157

So data and behavior 158

158

all packed into one nice, self-contained block. 159

159

But now let's use this class 160

160

and actually create a new object 161

161

from this class. 162

162

And you see that now we actually have 163

163

real data about the user and the object 164

164

and not just a description of the data 165

165

like we have in the class, so in the plan. 166

166

Now we call all objects created through a class 167

167

instances of that class. 168

168

So again, an instance is a real object 169

169

that we can use in our code, 170

170

which was created from a class, 171

171

and a class itself is not an object. 172

172

All right. 173

173

So back to the blueprint analogy from earlier, 174

174

this instance is like a real house, 175

175

which was created from the abstract blueprint 176

176

created by the architect. 177

177

And the beauty of this is that now 178

178

we can use this class to create as many instances 179

179

as we need in our application. 180

180

Just like we can build multiple houses 181

181

from just one blueprint, right? 182

182

And all of these instances, 183

183

so these objects, of course can have 184

184

different data in them, 185

185

but they all share the same functionality, 186

186

which is to login and to send messages. 187

187

Okay. 188

188

So now we know that we can create classes 189

189

to generate objects from these classes. 190

190

So we know how classes work, 191

191

but the next logical question is, 192

192

how do we actually design a class? 193

193

Or in other words, 194

194

how do we actually model 195

195

real-world data into classes? 196

196

So these questions are just 197

197

like an architecture student asking, 198

198

well, how do we actually plan 199

199

and design a house? 200

200

And that's of course a very good question. 201

201

Now the answer is, as you can imagine, 202

202

not straightforward. 203

203

So there is not a single correct way 204

204

of designing classes. 205

205

There are, however, four fundamental principles 206

206

that can guide us toward a good class implementation. 207

207

And these principles are abstraction, encapsulation, 208

208

inheritance, and polymorphism. 209

209

And these are actually techniques 210

210

that can also be used outside of OOP, 211

211

but they are especially relevant in this context. 212

212

So let's now take a more detailed look at each of them. 213

213

And the first one is abstraction. 214

214

And abstraction basically means 215

215

to ignore or to hide details 216

216

that don't matter. 217

217

This allows us to get an overview perspective 218

218

of whatever it is that we're implementing 219

219

instead of messing with details 220

220

that don't really matter to our implementation. 221

221

So let's say that we're implementing a phone 222

222

for a user to use. 223

223

And even though this doesn't make much sense in code, 224

224

it's still a great example and analogy. 225

225

So without abstraction 226

226

we could design our class 227

227

to include everything that there is about the phone, 228

228

including all the internal stuff 229

229

like verifying the phone's temperature and voltage, 230

230

turning on the vibration motor or the speaker, 231

231

and other low-level details. 232

232

But as a user interacting with a phone, 233

233

do we really need all of this detail? 234

234

Well, I guess not. 235

235

Right? 236

236

So in reality, when we interact with a real phone, 237

237

all of these details have been abstracted away 238

238

from us as the user. 239

239

And all that we're left with is a simple phone 240

240

that we basically only interact with 241

241

using the home button, 242

242

volume buttons and the screen. 243

243

Everything else is gone 244

244

because we simply don't need it as a user. 245

245

So the phone then operates kind of as a black box, 246

246

without us seeing what is happening inside. 247

247

Now, of course, internally 248

248

the phone still needs to vibrate 249

249

and to measure the voltage 250

250

or to turn on the speaker, 251

251

but we can hide these details from the user. 252

252

And that is exactly what abstraction means. 253

253

Now, going back to the example 254

254

of a user from the last slide, 255

255

we could implement a user's phone number, 256

256

mailing address, hair color, shoe size, 257

257

and tons of other stuff 258

258

that we might not need in our application. 259

259

So we simply ignore these details. 260

260

Now, abstraction is really important, 261

261

not just in OOP, 262

262

but in programming in general. 263

263

In fact, we create and use abstractions 264

264

all the time. 265

265

For example, take the add event listener function 266

266

that we use all the time. 267

267

Do we actually know how exactly it works 268

268

behind the scenes? 269

269

Well, we don't. 270

270

And do we care? 271

271

No, not really. 272

272

Right? 273

273

And we don't have to because once more, 274

274

the low-level details of how exactly it works 275

275

has been obstructed away from us. 276

276

We are simply the user. 277

277

And so we can simply use that function 278

278

without completely understanding it 279

279

and without having to implement it ourselves. 280

280

So that's abstraction, 281

281

which actually blends in with the next principle, 282

282

which is encapsulation. 283

283

And encapsulation basically means 284

284

to keep some properties 285

285

and methods private inside the class 286

286

so that they're not accessible 287

287

from outside the class. 288

288

However, some methods can, of course, 289

289

be exposed as a public interface, 290

290

which we call API. 291

291

And this is exactly what I meant 292

292

at the beginning of the lecture 293

293

when I said that interactions between objects 294

294

happen through a public interface. 295

295

And going back to our example of a user from before, 296

296

this is what private properties 297

297

might look like conceptually. 298

298

And again, I'm talking hypothetical here 299

299

because this private keyword here 300

300

actually does not exist in JavaScript. 301

301

But anyway, as we already know, 302

302

outside code now can't access these properties. 303

303

However, inside the class, 304

304

they are still accessible. 305

305

For example, the password is, of course, necessary 306

306

in the login method, right? 307

307

And so there we can use it. 308

308

And by having these critical properties 309

309

nicely encapsulated like this, 310

310

we prevent external code 311

311

from accidentally manipulating this internal state. 312

312

And by the way, the term state simply refers 313

313

to an object's data. 314

314

Okay. 315

315

Anyway, this is really important 316

316

because allowing external code 317

317

to manipulate internal state directly 318

318

can cause many kinds of bugs, 319

319

especially in large code bases 320

320

and developer teams. 321

321

Now, as you see, there's also a private method here, 322

322

the check spam method. 323

323

Again, it's not accessible from outside a class, 324

324

but it's used internally 325

325

to check if a comment is spam or not. 326

326

So we want no one else outside of the class 327

327

to be able to use this method, 328

328

and so basically we don't make it 329

329

part of the public interface. 330

330

So the public interface 331

331

is essentially all the methods 332

332

that are not private, 333

333

so that are not encapsulated. 334

334

So making methods private 335

335

makes it easier for us to change our code 336

336

without breaking code from the outside, 337

337

which might rely on some of these methods. 338

338

For example, if the check spam method was public, 339

339

then it could be used anywhere in our code. 340

340

And if we then changed the implementation of the method, 341

341

it might break that code that is relying on it. 342

342

So again, this helps avoiding bugs 343

343

and also spaghetti code. 344

344

And really this is not just some theory, 345

345

this is a real practical scenario. 346

346

Alright. 347

347

So there is a real reason why encapsulation 348

348

and private methods and properties exist. 349

349

So in summary, we should always have the goal 350

350

to nicely encapsulate most of our state and methods 351

351

and only leaving essential methods public 352

352

for the reasons that I just explained. 353

353

Next up, we have inheritance. 354

354

So let's say we have these two classes, 355

355

user and admin, 356

356

which stands for administrator. 357

357

And as we can see, they have actually 358

358

a lot in common. 359

359

In fact, admin has all the properties 360

360

and methods that user has. 361

361

Right? 362

362

And that actually makes sense 363

363

because if you think about it, 364

364

an admin is also a user. 365

365

So an admin also needs a password and an email, 366

366

and he also needs to log in, for example. 367

367

However, if we design our classes like this, 368

368

so as two separate identities, 369

369

we will end up with a lot of duplicate code 370

370

and we already know that that's bad. 371

371

Right? 372

372

But well, that's where inheritance 373

373

comes into play. 374

374

So in OOP, when we have two classes 375

375

that are closely related, 376

376

like user and admin here, 377

377

we can have one class inherit from the other. 378

378

So we will have one parent class 379

379

and one child class, and the child class 380

380

then extends the parent class. 381

381

Okay, great. 382

382

But what does all of that actually mean? 383

383

Well, it's actually quite intuitive, I think. 384

384

So just like you as a child 385

385

probably inherited some features of your parents, 386

386

a child class inherits all the properties 387

387

and methods from its parent class. 388

388

Now, in more formal terms, 389

389

inheritance makes all properties and methods 390

390

of a certain class available to a child class, 391

391

which of course then forms a hierarchy 392

392

between these two classes. 393

393

And the goal of this is to reuse logic 394

394

that is common to both of the classes. 395

395

In this case, both the admin 396

396

and the user need to log in. 397

397

And so instead of writing that logic twice, 398

398

it makes sense to inherit the login method 399

399

from the more global class, 400

400

which is the parent class user, 401

401

to the more specific class, 402

402

which is the child class admin. 403

403

Now of course a child class can then also have 404

404

its own methods and properties. 405

405

So at the end of the day, 406

406

the child class ends up with some methods 407

407

and properties from its parent 408

408

and some of its own. 409

409

So we can say that the admin is also a user, 410

410

but basically an extended user, 411

411

so with some added functionality. 412

412

Okay. 413

413

And finally, the last principle is polymorphism. 414

414

And polymorphism sounds a bit weird, 415

415

which is because it comes from Greek, 416

416

where it literally means "many shapes". 417

417

Now, in the context of OOP, 418

418

in simple terms, polymorphism means 419

419

that a child class can overwrite a method 420

420

that it inherited from a parent class. 421

421

And here are our user and admin classes again. 422

422

But now we also have a third class, 423

423

which is the author. 424

424

Now admin and author are both 425

425

really just special kinds of users, 426

426

and so it makes sense that they both inherit 427

427

from the user class, 428

428

just like we studied in the last slide. 429

429

Therefore, they inherit all the properties 430

430

and methods from the user class, 431

431

but we're gonna focus on the login method now. 432

432

Now let's say that an admin requires 433

433

a different kind of login method. 434

434

For example, a more secure one, 435

435

which has two-factor authentication. 436

436

And let's say that we also need 437

437

a special login method for authors. 438

438

So how do we give them different login methods? 439

439

Well, it's actually quite simple. 440

440

In each class we simply just write a new method, 441

441

which is also called login. 442

442

And then, according to polymorphism, 443

443

that login method will overwrite 444

444

the login method that has been inherited 445

445

from the user class. 446

446

And that's actually it. 447

447

That's all you need to know about polymorphism. 448

448

And actually that wraps up this introduction 449

449

to object-oriented programming. 450

450

So I know there was a lot to take in here, 451

451

so make sure to understand everything 452

452

before actually moving on in this section. 453

453

Now, next up, we're gonna talk about 454

454

how object-oriented programming 455

455

actually looks like in JavaScript. 456

456

Because, as I said in the beginning, 457

457

it is implemented in a bit different way 458

458

from what I explained here in the beginning 459

459

with classes and instances. 460

460

It's still crucial to understand that, 461

461

but again, in the next video, 462

462

we will see how JavaScript does it.