WEBVTT 1 00:01.160 --> 00:02.230 So this section 2 00:02.230 --> 00:05.040 is about object-oriented programming, 3 00:05.040 --> 00:07.030 and this lecture is gonna be 4 00:07.030 --> 00:10.020 a very general, high level overview 5 00:10.020 --> 00:12.780 of this programming paradigm. 6 00:12.780 --> 00:14.360 So we're gonna talk about 7 00:14.360 --> 00:16.860 what object-oriented programming is, 8 00:16.860 --> 00:18.860 how it works in general, 9 00:18.860 --> 00:22.160 and about its four fundamental principles. 10 00:22.160 --> 00:24.790 So this is gonna be a really important 11 00:24.790 --> 00:26.700 and valuable lecture. 12 00:26.700 --> 00:28.753 And so let's get started. 13 00:30.200 --> 00:34.770 So, first of all, what is object-oriented programming? 14 00:34.770 --> 00:37.460 Well, object-oriented programming, 15 00:37.460 --> 00:39.720 or OOP in short, 16 00:39.720 --> 00:42.530 is a programming paradigm that is based 17 00:42.530 --> 00:45.270 on the concept of objects. 18 00:45.270 --> 00:47.270 And paradigm simply means 19 00:47.270 --> 00:49.130 the style of the code, 20 00:49.130 --> 00:53.330 so the how we write and organize code. 21 00:53.330 --> 00:56.020 Now we use objects to model, 22 00:56.020 --> 00:59.500 so to describe aspects of the real world, 23 00:59.500 --> 01:02.850 like a user or a to-do list item, 24 01:02.850 --> 01:05.060 or even more abstract features 25 01:05.060 --> 01:07.150 like an HTML component 26 01:07.150 --> 01:09.693 or some kind of data structure. 27 01:10.640 --> 01:14.710 Now, as we already know, objects can contain data, 28 01:14.710 --> 01:17.750 which we call properties, and also code, 29 01:17.750 --> 01:19.690 which we call methods. 30 01:19.690 --> 01:22.400 So we can say that by using objects, 31 01:22.400 --> 01:24.280 we pack all the data 32 01:24.280 --> 01:26.410 and the corresponding behavior 33 01:26.410 --> 01:29.080 all into one big block. 34 01:29.080 --> 01:33.010 So again, that's data and corresponding behavior. 35 01:33.010 --> 01:34.870 And this makes it super easy 36 01:34.870 --> 01:38.140 to act directly on the data. 37 01:38.140 --> 01:39.870 And speaking of blocks, 38 01:39.870 --> 01:43.560 that's exactly what objects are supposed to be. 39 01:43.560 --> 01:46.340 So in OOP, which is the acronym 40 01:46.340 --> 01:50.170 that I'm gonna use instead of object-oriented programming. 41 01:50.170 --> 01:51.500 Okay. 42 01:51.500 --> 01:56.460 So in OOP objects are self-contained pieces of code 43 01:56.460 --> 01:58.030 or blocks of code, 44 01:58.030 --> 02:01.250 like small applications on their own. 45 02:01.250 --> 02:03.200 And we then use these objects 46 02:03.200 --> 02:06.150 as building blocks of our applications 47 02:06.150 --> 02:09.313 and make objects interact with one another. 48 02:10.150 --> 02:12.340 Now these interactions happen 49 02:12.340 --> 02:15.270 through a so-called public interface, 50 02:15.270 --> 02:17.920 which we also call API. 51 02:17.920 --> 02:21.330 This interface is basically a bunch of methods 52 02:21.330 --> 02:23.730 that a code outside of the objects 53 02:23.730 --> 02:27.350 can access and that we use to communicate 54 02:27.350 --> 02:28.503 with the object. 55 02:29.690 --> 02:30.610 Okay. 56 02:30.610 --> 02:32.770 So let's take a breath here 57 02:32.770 --> 02:36.850 because this all sounds kind of abstract, right? 58 02:36.850 --> 02:37.900 But don't worry. 59 02:37.900 --> 02:39.360 It will make more sense 60 02:39.360 --> 02:41.750 once we start developing these concepts 61 02:41.750 --> 02:44.860 using code throughout this section. 62 02:44.860 --> 02:49.860 But anyway, why does OOP actually exist? 63 02:49.870 --> 02:52.500 Well, this paradigm was developed 64 02:52.500 --> 02:55.350 with the goal of organizing code, 65 02:55.350 --> 02:57.300 so to make it more flexible 66 02:57.300 --> 02:59.670 and easier to maintain. 67 02:59.670 --> 03:03.290 So before OOP, we might have a bunch of codes 68 03:03.290 --> 03:06.110 gathered across multiple functions, 69 03:06.110 --> 03:08.010 or even in the global scope 70 03:08.010 --> 03:10.300 without any structure. 71 03:10.300 --> 03:13.980 And this particular like crazy style of code 72 03:13.980 --> 03:16.290 is what we usually call spaghetti code 73 03:17.300 --> 03:19.770 and spaghetti code makes it very hard 74 03:19.770 --> 03:22.170 to maintain large code bases 75 03:22.170 --> 03:26.210 and let alone, add new functionalities to it. 76 03:26.210 --> 03:30.080 So the idea of OOP was basically created 77 03:30.080 --> 03:32.840 as a solution to this problem. 78 03:32.840 --> 03:36.310 And apparently it worked because today, 79 03:36.310 --> 03:38.971 OOP is probably the most popular 80 03:38.971 --> 03:41.930 and most widely used programming paradigm 81 03:41.930 --> 03:44.473 in large scale software engineering. 82 03:45.310 --> 03:48.970 Now, OOP is certainly not the only way 83 03:48.970 --> 03:52.330 of writing organized and maintainable code. 84 03:52.330 --> 03:55.200 So in fact, there're many other paradigms 85 03:55.200 --> 03:57.840 that have become increasingly popular 86 03:57.840 --> 04:00.480 and one of them is functional programming. 87 04:00.480 --> 04:02.770 And functional programming allows us 88 04:02.770 --> 04:05.090 to achieve the exact same goal 89 04:05.090 --> 04:08.040 of basically avoiding spaghetti code. 90 04:08.040 --> 04:09.500 And as I have been saying, 91 04:09.500 --> 04:11.550 we will talk about functional programming 92 04:11.550 --> 04:14.040 later in the course and compare it 93 04:14.040 --> 04:16.580 with object-oriented programming. 94 04:16.580 --> 04:19.067 But for now, let's focus on OOP. 95 04:21.270 --> 04:23.730 Now, actually using objects 96 04:23.730 --> 04:27.550 is nothing new for us at this point, right? 97 04:27.550 --> 04:30.230 We have been using them all the time. 98 04:30.230 --> 04:32.320 However, up until now, 99 04:32.320 --> 04:34.770 we have basically only used objects 100 04:34.770 --> 04:37.190 as loose collections of data 101 04:37.190 --> 04:40.780 and without making them interact with one another. 102 04:40.780 --> 04:42.400 Also, we didn't have a way 103 04:42.400 --> 04:45.160 to generate objects programmatically. 104 04:45.160 --> 04:49.200 All we ever did was using simple object literals, 105 04:49.200 --> 04:53.270 but in OOP, we actually need a way to generate, 106 04:53.270 --> 04:57.240 so to create, new objects from our code. 107 04:57.240 --> 05:00.360 And to do that in traditional OOP, 108 05:00.360 --> 05:03.270 we use something called classes. 109 05:03.270 --> 05:06.400 You can think of a class as a blueprint, 110 05:06.400 --> 05:09.470 which can then be used to create new objects 111 05:09.470 --> 05:13.030 based on the rules described in the class. 112 05:13.030 --> 05:15.570 So it's just like an architecture 113 05:15.570 --> 05:18.160 where the architect develops a blueprint 114 05:18.160 --> 05:21.270 to exactly plan and describe a house. 115 05:21.270 --> 05:24.780 But the blueprint is really just an abstract plan, 116 05:24.780 --> 05:26.350 like a set of rules, 117 05:26.350 --> 05:30.270 but nothing tangible that you can actually touch. 118 05:30.270 --> 05:32.490 However, from that blueprint, 119 05:32.490 --> 05:35.080 many real houses can then be built 120 05:35.080 --> 05:36.800 in the real world. 121 05:36.800 --> 05:39.970 And with classes it's just the same. 122 05:39.970 --> 05:43.560 So let's take a look at this fictional user class 123 05:43.560 --> 05:45.130 as an example. 124 05:45.130 --> 05:46.710 And I say fictional 125 05:46.710 --> 05:50.070 because this is not actual JavaScript syntax. 126 05:50.070 --> 05:51.020 Okay. 127 05:51.020 --> 05:54.150 Because JavaScript does not actually support 128 05:54.150 --> 05:57.540 real classes like I'm explaining here. 129 05:57.540 --> 06:00.970 We do have a class syntax in JavaScript too, 130 06:00.970 --> 06:03.280 but it still works a bit differently 131 06:03.280 --> 06:05.530 from what I'm gonna show you here. 132 06:05.530 --> 06:08.300 However, the idea of creating objects 133 06:08.300 --> 06:09.880 from a kind of blueprint 134 06:09.880 --> 06:13.600 is still a very useful mental model to have. 135 06:13.600 --> 06:15.590 Because in general terms, 136 06:15.590 --> 06:17.880 this is still how OOP works 137 06:17.880 --> 06:19.680 across all languages 138 06:19.680 --> 06:21.770 and that includes JavaScript. 139 06:21.770 --> 06:23.080 And so that's the reason 140 06:23.080 --> 06:24.920 why I'm showing you this here, 141 06:24.920 --> 06:27.030 so as a conceptual overview, 142 06:27.030 --> 06:30.240 and for you to have this as a mental model. 143 06:30.240 --> 06:33.740 But anyway, back to our fictional class here, 144 06:33.740 --> 06:37.040 we can see that it kind of describes a user 145 06:37.040 --> 06:41.350 who has a username, a password, and an email. 146 06:41.350 --> 06:45.030 So it's a description of data about a user, 147 06:45.030 --> 06:47.490 but it's not the data itself yet. 148 06:47.490 --> 06:51.510 Because remember, the class is really just a plan 149 06:51.510 --> 06:55.770 and a plan doesn't contain the real world data just yet. 150 06:55.770 --> 06:58.860 On the other hand, we then have the behavior 151 06:58.860 --> 07:01.490 that is associated with the data. 152 07:01.490 --> 07:02.510 And in this case, 153 07:02.510 --> 07:04.590 that's just a login method 154 07:04.590 --> 07:07.530 and a method to send messages. 155 07:07.530 --> 07:10.310 So just like we learned in the last slide, 156 07:10.310 --> 07:13.810 this class has everything related to a user. 157 07:13.810 --> 07:15.930 So data and behavior 158 07:15.930 --> 07:19.403 all packed into one nice, self-contained block. 159 07:20.290 --> 07:22.510 But now let's use this class 160 07:22.510 --> 07:24.730 and actually create a new object 161 07:24.730 --> 07:26.660 from this class. 162 07:26.660 --> 07:29.210 And you see that now we actually have 163 07:29.210 --> 07:32.330 real data about the user and the object 164 07:32.330 --> 07:34.930 and not just a description of the data 165 07:34.930 --> 07:38.870 like we have in the class, so in the plan. 166 07:38.870 --> 07:42.500 Now we call all objects created through a class 167 07:42.500 --> 07:45.370 instances of that class. 168 07:45.370 --> 07:48.903 So again, an instance is a real object 169 07:48.903 --> 07:50.970 that we can use in our code, 170 07:50.970 --> 07:53.940 which was created from a class, 171 07:53.940 --> 07:57.020 and a class itself is not an object. 172 07:57.020 --> 07:58.590 All right. 173 07:58.590 --> 08:02.010 So back to the blueprint analogy from earlier, 174 08:02.010 --> 08:04.980 this instance is like a real house, 175 08:04.980 --> 08:07.830 which was created from the abstract blueprint 176 08:07.830 --> 08:10.580 created by the architect. 177 08:10.580 --> 08:13.120 And the beauty of this is that now 178 08:13.120 --> 08:16.410 we can use this class to create as many instances 179 08:16.410 --> 08:18.820 as we need in our application. 180 08:18.820 --> 08:21.380 Just like we can build multiple houses 181 08:21.380 --> 08:24.380 from just one blueprint, right? 182 08:24.380 --> 08:26.290 And all of these instances, 183 08:26.290 --> 08:28.760 so these objects, of course can have 184 08:28.760 --> 08:30.200 different data in them, 185 08:30.200 --> 08:32.820 but they all share the same functionality, 186 08:32.820 --> 08:35.873 which is to login and to send messages. 187 08:37.950 --> 08:38.960 Okay. 188 08:38.960 --> 08:41.740 So now we know that we can create classes 189 08:41.740 --> 08:45.130 to generate objects from these classes. 190 08:45.130 --> 08:47.320 So we know how classes work, 191 08:47.320 --> 08:49.750 but the next logical question is, 192 08:49.750 --> 08:52.740 how do we actually design a class? 193 08:52.740 --> 08:54.090 Or in other words, 194 08:54.090 --> 08:55.640 how do we actually model 195 08:55.640 --> 08:58.720 real-world data into classes? 196 08:58.720 --> 09:00.710 So these questions are just 197 09:00.710 --> 09:03.380 like an architecture student asking, 198 09:03.380 --> 09:05.450 well, how do we actually plan 199 09:05.450 --> 09:07.420 and design a house? 200 09:07.420 --> 09:10.820 And that's of course a very good question. 201 09:10.820 --> 09:13.450 Now the answer is, as you can imagine, 202 09:13.450 --> 09:15.440 not straightforward. 203 09:15.440 --> 09:17.690 So there is not a single correct way 204 09:17.690 --> 09:19.770 of designing classes. 205 09:19.770 --> 09:23.290 There are, however, four fundamental principles 206 09:23.290 --> 09:27.300 that can guide us toward a good class implementation. 207 09:27.300 --> 09:31.010 And these principles are abstraction, encapsulation, 208 09:31.010 --> 09:34.090 inheritance, and polymorphism. 209 09:34.090 --> 09:36.070 And these are actually techniques 210 09:36.070 --> 09:39.560 that can also be used outside of OOP, 211 09:39.560 --> 09:43.520 but they are especially relevant in this context. 212 09:43.520 --> 09:46.853 So let's now take a more detailed look at each of them. 213 09:48.350 --> 09:51.190 And the first one is abstraction. 214 09:51.190 --> 09:52.940 And abstraction basically means 215 09:52.940 --> 09:56.040 to ignore or to hide details 216 09:56.040 --> 09:57.860 that don't matter. 217 09:57.860 --> 10:00.880 This allows us to get an overview perspective 218 10:00.880 --> 10:03.690 of whatever it is that we're implementing 219 10:03.690 --> 10:05.790 instead of messing with details 220 10:05.790 --> 10:09.500 that don't really matter to our implementation. 221 10:09.500 --> 10:12.170 So let's say that we're implementing a phone 222 10:12.170 --> 10:14.300 for a user to use. 223 10:14.300 --> 10:17.570 And even though this doesn't make much sense in code, 224 10:17.570 --> 10:20.243 it's still a great example and analogy. 225 10:21.200 --> 10:23.300 So without abstraction 226 10:23.300 --> 10:24.790 we could design our class 227 10:24.790 --> 10:28.450 to include everything that there is about the phone, 228 10:28.450 --> 10:30.530 including all the internal stuff 229 10:30.530 --> 10:34.400 like verifying the phone's temperature and voltage, 230 10:34.400 --> 10:37.590 turning on the vibration motor or the speaker, 231 10:37.590 --> 10:40.070 and other low-level details. 232 10:40.070 --> 10:42.800 But as a user interacting with a phone, 233 10:42.800 --> 10:45.750 do we really need all of this detail? 234 10:45.750 --> 10:47.700 Well, I guess not. 235 10:47.700 --> 10:48.870 Right? 236 10:48.870 --> 10:52.680 So in reality, when we interact with a real phone, 237 10:52.680 --> 10:55.790 all of these details have been abstracted away 238 10:55.790 --> 10:57.840 from us as the user. 239 10:57.840 --> 11:00.993 And all that we're left with is a simple phone 240 11:00.993 --> 11:03.250 that we basically only interact with 241 11:03.250 --> 11:04.800 using the home button, 242 11:04.800 --> 11:07.370 volume buttons and the screen. 243 11:07.370 --> 11:09.110 Everything else is gone 244 11:09.110 --> 11:12.640 because we simply don't need it as a user. 245 11:12.640 --> 11:15.960 So the phone then operates kind of as a black box, 246 11:15.960 --> 11:19.530 without us seeing what is happening inside. 247 11:19.530 --> 11:21.240 Now, of course, internally 248 11:21.240 --> 11:23.610 the phone still needs to vibrate 249 11:23.610 --> 11:25.440 and to measure the voltage 250 11:25.440 --> 11:27.300 or to turn on the speaker, 251 11:27.300 --> 11:30.370 but we can hide these details from the user. 252 11:30.370 --> 11:34.120 And that is exactly what abstraction means. 253 11:34.120 --> 11:35.950 Now, going back to the example 254 11:35.950 --> 11:38.400 of a user from the last slide, 255 11:38.400 --> 11:40.700 we could implement a user's phone number, 256 11:40.700 --> 11:44.040 mailing address, hair color, shoe size, 257 11:44.040 --> 11:46.110 and tons of other stuff 258 11:46.110 --> 11:49.150 that we might not need in our application. 259 11:49.150 --> 11:51.573 So we simply ignore these details. 260 11:52.550 --> 11:55.380 Now, abstraction is really important, 261 11:55.380 --> 11:57.220 not just in OOP, 262 11:57.220 --> 11:59.560 but in programming in general. 263 11:59.560 --> 12:02.630 In fact, we create and use abstractions 264 12:02.630 --> 12:04.170 all the time. 265 12:04.170 --> 12:07.230 For example, take the add event listener function 266 12:07.230 --> 12:09.260 that we use all the time. 267 12:09.260 --> 12:11.880 Do we actually know how exactly it works 268 12:11.880 --> 12:13.620 behind the scenes? 269 12:13.620 --> 12:15.540 Well, we don't. 270 12:15.540 --> 12:17.420 And do we care? 271 12:17.420 --> 12:18.970 No, not really. 272 12:18.970 --> 12:19.970 Right? 273 12:19.970 --> 12:23.410 And we don't have to because once more, 274 12:23.410 --> 12:26.670 the low-level details of how exactly it works 275 12:26.670 --> 12:29.400 has been abstracted away from us. 276 12:29.400 --> 12:31.020 We are simply the user. 277 12:31.020 --> 12:33.630 And so we can simply use that function 278 12:33.630 --> 12:35.880 without completely understanding it 279 12:35.880 --> 12:38.950 and without having to implement it ourselves. 280 12:38.950 --> 12:40.820 So that's abstraction, 281 12:40.820 --> 12:43.710 which actually blends in with the next principle, 282 12:43.710 --> 12:45.503 which is encapsulation. 283 12:47.090 --> 12:49.340 And encapsulation basically means 284 12:49.340 --> 12:50.760 to keep some properties 285 12:50.760 --> 12:54.220 and methods private inside the class 286 12:54.220 --> 12:56.280 so that they're not accessible 287 12:56.280 --> 12:58.130 from outside the class. 288 12:58.130 --> 13:00.430 However, some methods can, of course, 289 13:00.430 --> 13:03.590 be exposed as a public interface, 290 13:03.590 --> 13:05.570 which we call API. 291 13:05.570 --> 13:07.570 And this is exactly what I meant 292 13:07.570 --> 13:09.180 at the beginning of the lecture 293 13:09.180 --> 13:12.210 when I said that interactions between objects 294 13:12.210 --> 13:15.230 happen through a public interface. 295 13:15.230 --> 13:19.450 And going back to our example of a user from before, 296 13:19.450 --> 13:21.410 this is what private properties 297 13:21.410 --> 13:23.950 might look like conceptually. 298 13:23.950 --> 13:26.800 And again, I'm talking hypothetical here 299 13:26.800 --> 13:28.900 because this private keyword here 300 13:28.900 --> 13:32.340 actually does not exist in JavaScript. 301 13:32.340 --> 13:34.880 But anyway, as we already know, 302 13:34.880 --> 13:39.020 outside code now can't access these properties. 303 13:39.020 --> 13:41.220 However, inside the class, 304 13:41.220 --> 13:43.170 they are still accessible. 305 13:43.170 --> 13:46.190 For example, the password is, of course, necessary 306 13:46.190 --> 13:48.600 in the login method, right? 307 13:48.600 --> 13:51.140 And so there we can use it. 308 13:51.140 --> 13:53.460 And by having these critical properties 309 13:53.460 --> 13:55.930 nicely encapsulated like this, 310 13:55.930 --> 13:57.710 we prevent external code 311 13:57.710 --> 14:01.760 from accidentally manipulating this internal state. 312 14:01.760 --> 14:05.270 And by the way, the term state simply refers 313 14:05.270 --> 14:07.180 to an object's data. 314 14:07.180 --> 14:08.670 Okay. 315 14:08.670 --> 14:11.360 Anyway, this is really important 316 14:11.360 --> 14:13.550 because allowing external code 317 14:13.550 --> 14:16.690 to manipulate internal state directly 318 14:16.690 --> 14:19.080 can cause many kinds of bugs, 319 14:19.080 --> 14:21.450 especially in large code bases 320 14:21.450 --> 14:23.460 and developer teams. 321 14:23.460 --> 14:27.320 Now, as you see, there's also a private method here, 322 14:27.320 --> 14:29.540 the check spam method. 323 14:29.540 --> 14:33.380 Again, it's not accessible from outside a class, 324 14:33.380 --> 14:35.190 but it's used internally 325 14:35.190 --> 14:38.640 to check if a comment is spam or not. 326 14:38.640 --> 14:41.760 So we want no one else outside of the class 327 14:41.760 --> 14:44.100 to be able to use this method, 328 14:44.100 --> 14:46.010 and so basically we don't make it 329 14:46.010 --> 14:48.930 part of the public interface. 330 14:48.930 --> 14:50.570 So the public interface 331 14:50.570 --> 14:52.550 is essentially all the methods 332 14:52.550 --> 14:54.310 that are not private, 333 14:54.310 --> 14:56.093 so that are not encapsulated. 334 14:57.280 --> 14:59.390 So making methods private 335 14:59.390 --> 15:02.170 makes it easier for us to change our code 336 15:02.170 --> 15:05.000 without breaking code from the outside, 337 15:05.000 --> 15:08.850 which might rely on some of these methods. 338 15:08.850 --> 15:12.900 For example, if the check spam method was public, 339 15:12.900 --> 15:15.990 then it could be used anywhere in our code. 340 15:15.990 --> 15:19.220 And if we then changed the implementation of the method, 341 15:19.220 --> 15:23.210 it might break that code that is relying on it. 342 15:23.210 --> 15:25.970 So again, this helps avoiding bugs 343 15:25.970 --> 15:28.490 and also spaghetti code. 344 15:28.490 --> 15:31.950 And really this is not just some theory, 345 15:31.950 --> 15:34.730 this is a real practical scenario. 346 15:34.730 --> 15:35.600 Alright. 347 15:35.600 --> 15:38.710 So there is a real reason why encapsulation 348 15:38.710 --> 15:42.330 and private methods and properties exist. 349 15:42.330 --> 15:45.320 So in summary, we should always have the goal 350 15:45.320 --> 15:49.710 to nicely encapsulate most of our state and methods 351 15:49.710 --> 15:52.610 and only leaving essential methods public 352 15:52.610 --> 15:55.243 for the reasons that I just explained. 353 15:57.560 --> 16:00.220 Next up, we have inheritance. 354 16:00.220 --> 16:03.010 So let's say we have these two classes, 355 16:03.010 --> 16:04.960 user and admin, 356 16:04.960 --> 16:07.410 which stands for administrator. 357 16:07.410 --> 16:10.000 And as we can see, they have actually 358 16:10.000 --> 16:12.220 a lot in common. 359 16:12.220 --> 16:15.000 In fact, admin has all the properties 360 16:15.000 --> 16:17.630 and methods that user has. 361 16:17.630 --> 16:18.660 Right? 362 16:18.660 --> 16:20.770 And that actually makes sense 363 16:20.770 --> 16:22.700 because if you think about it, 364 16:22.700 --> 16:25.690 an admin is also a user. 365 16:25.690 --> 16:29.320 So an admin also needs a password and an email, 366 16:29.320 --> 16:32.690 and he also needs to log in, for example. 367 16:32.690 --> 16:36.200 However, if we design our classes like this, 368 16:36.200 --> 16:38.470 so as two separate identities, 369 16:38.470 --> 16:41.680 we will end up with a lot of duplicate code 370 16:41.680 --> 16:44.480 and we already know that that's bad. 371 16:44.480 --> 16:45.400 Right? 372 16:45.400 --> 16:47.630 But well, that's where inheritance 373 16:47.630 --> 16:49.580 comes into play. 374 16:49.580 --> 16:52.860 So in OOP, when we have two classes 375 16:52.860 --> 16:54.860 that are closely related, 376 16:54.860 --> 16:57.050 like user and admin here, 377 16:57.050 --> 17:01.010 we can have one class inherit from the other. 378 17:01.010 --> 17:03.420 So we will have one parent class 379 17:03.420 --> 17:06.640 and one child class, and the child class 380 17:06.640 --> 17:09.930 then extends the parent class. 381 17:09.930 --> 17:11.750 Okay, great. 382 17:11.750 --> 17:15.170 But what does all of that actually mean? 383 17:15.170 --> 17:18.950 Well, it's actually quite intuitive, I think. 384 17:18.950 --> 17:21.160 So just like you as a child 385 17:21.160 --> 17:24.910 probably inherited some features of your parents, 386 17:24.910 --> 17:27.580 a child class inherits all the properties 387 17:27.580 --> 17:30.850 and methods from its parent class. 388 17:30.850 --> 17:32.830 Now, in more formal terms, 389 17:32.830 --> 17:35.640 inheritance makes all properties and methods 390 17:35.640 --> 17:39.890 of a certain class available to a child class, 391 17:39.890 --> 17:43.050 which of course then forms a hierarchy 392 17:43.050 --> 17:45.260 between these two classes. 393 17:45.260 --> 17:47.980 And the goal of this is to reuse logic 394 17:47.980 --> 17:51.080 that is common to both of the classes. 395 17:51.080 --> 17:52.980 In this case, both the admin 396 17:52.980 --> 17:55.230 and the user need to log in. 397 17:55.230 --> 17:58.430 And so instead of writing that logic twice, 398 17:58.430 --> 18:01.620 it makes sense to inherit the login method 399 18:01.620 --> 18:03.480 from the more global class, 400 18:03.480 --> 18:05.750 which is the parent class user, 401 18:05.750 --> 18:07.600 to the more specific class, 402 18:07.600 --> 18:10.540 which is the child class admin. 403 18:10.540 --> 18:13.770 Now of course a child class can then also have 404 18:13.770 --> 18:16.520 its own methods and properties. 405 18:16.520 --> 18:18.020 So at the end of the day, 406 18:18.020 --> 18:20.500 the child class ends up with some methods 407 18:20.500 --> 18:22.950 and properties from its parent 408 18:22.950 --> 18:24.890 and some of its own. 409 18:24.890 --> 18:28.285 So we can say that the admin is also a user, 410 18:28.285 --> 18:31.280 but basically an extended user, 411 18:31.280 --> 18:33.633 so with some added functionality. 412 18:35.270 --> 18:36.270 Okay. 413 18:36.270 --> 18:40.200 And finally, the last principle is polymorphism. 414 18:40.200 --> 18:43.620 And polymorphism sounds a bit weird, 415 18:43.620 --> 18:46.090 which is because it comes from Greek, 416 18:46.090 --> 18:49.260 where it literally means "many shapes". 417 18:49.260 --> 18:51.127 Now, in the context of OOP, 418 18:51.980 --> 18:54.600 in simple terms, polymorphism means 419 18:54.600 --> 18:57.553 that a child class can overwrite a method 420 18:57.553 --> 19:00.980 that it inherited from a parent class. 421 19:00.980 --> 19:04.760 And here are our user and admin classes again. 422 19:04.760 --> 19:07.320 But now we also have a third class, 423 19:07.320 --> 19:09.110 which is the author. 424 19:09.110 --> 19:11.320 Now admin and author are both 425 19:11.320 --> 19:14.440 really just special kinds of users, 426 19:14.440 --> 19:17.150 and so it makes sense that they both inherit 427 19:17.150 --> 19:18.720 from the user class, 428 19:18.720 --> 19:21.840 just like we studied in the last slide. 429 19:21.840 --> 19:24.210 Therefore, they inherit all the properties 430 19:24.210 --> 19:26.870 and methods from the user class, 431 19:26.870 --> 19:30.410 but we're gonna focus on the login method now. 432 19:30.410 --> 19:32.870 Now let's say that an admin requires 433 19:32.870 --> 19:35.580 a different kind of login method. 434 19:35.580 --> 19:37.470 For example, a more secure one, 435 19:37.470 --> 19:39.803 which has two-factor authentication. 436 19:40.680 --> 19:42.300 And let's say that we also need 437 19:42.300 --> 19:45.460 a special login method for authors. 438 19:45.460 --> 19:49.220 So how do we give them different login methods? 439 19:49.220 --> 19:51.910 Well, it's actually quite simple. 440 19:51.910 --> 19:55.410 In each class we simply just write a new method, 441 19:55.410 --> 19:57.780 which is also called login. 442 19:57.780 --> 20:00.430 And then, according to polymorphism, 443 20:00.430 --> 20:02.680 that login method will overwrite 444 20:02.680 --> 20:05.370 the login method that has been inherited 445 20:05.370 --> 20:07.470 from the user class. 446 20:07.470 --> 20:09.160 And that's actually it. 447 20:09.160 --> 20:11.913 That's all you need to know about polymorphism. 448 20:12.870 --> 20:16.280 And actually that wraps up this introduction 449 20:16.280 --> 20:19.000 to object-oriented programming. 450 20:19.000 --> 20:22.270 So I know there was a lot to take in here, 451 20:22.270 --> 20:24.840 so make sure to understand everything 452 20:24.840 --> 20:28.100 before actually moving on in this section. 453 20:28.100 --> 20:30.320 Now, next up, we're gonna talk about 454 20:30.320 --> 20:32.490 how object-oriented programming 455 20:32.490 --> 20:35.220 actually looks like in JavaScript. 456 20:35.220 --> 20:37.470 Because, as I said in the beginning, 457 20:37.470 --> 20:40.050 it is implemented in a bit different way 458 20:40.050 --> 20:42.330 from what I explained here in the beginning 459 20:42.330 --> 20:45.180 with classes and instances. 460 20:45.180 --> 20:47.840 It's still crucial to understand that, 461 20:47.840 --> 20:49.820 but again, in the next video, 462 20:49.820 --> 20:52.173 we will see how JavaScript does it.