Python for the .NET developer Transcripts
Chapter: OOP: Object-Oriented Python
Lecture: Concept: Defining classes in Python
0:00 Time to review creating a base class or
0:02 super class in Python.
0:04 Our car class was our super class
0:07 and we wanted to be abstract so here
0:09 we derive from ABC, Abstract Based Class.
0:12 Has a couple of features has a constructor
0:15 and C# terminology, an initializer
0:17 or sometimes referred to as
0:18 dunder init, as in __init__
0:23 Though dunder init, you'll hear that a lot
0:25 dunder methods for this class of methods.
0:28 And these are the special built-ins
0:30 like the operator stuff I showed you
0:31 and so on.
0:32 So we are going to create one of those
0:33 and it is going to take whatever
0:35 data we have to pass to the class to get it started
0:37 model name, engine type, cylinders and base price.
0:39 We went ahead and used the typing to
0:41 make that really obvious.
0:42 And to define 'fields' by the same names
0:45 we are going to say self.model_name
0:48 self.base_price, self.cylinders.
0:51 Now, we didn't talk about this in the demo
0:53 but I'm going to mention it here.
0:54 IF you want this to be a private field
0:56 use the double underscore at the beginning.
0:59 It is a weird convention
1:00 Python is all about the underscores
1:02 and sometimes they are just separators
1:05 like base price.
1:06 Other times they have important meaning.
1:08 If the underscore is a single underscore
1:10 in the beginning
1:11 it's still publicly visible
1:12 the field or the method that you gave that name
1:14 but it is indicated, like its
1:16 you probably should stay away from it.
1:17 It's kind of an internal thing
1:19 leave it alone.
1:20 You put a double underscore
1:21 the runtime will actually change it's value
1:24 so you effectively can't simply can't easily
1:27 without jumping through a bunch of hoops
1:28 you can't get to it from the outside.
1:30 So when you say car.__engine_type should not appear.
1:33 Depending on your editor, but certainly
1:36 and working with it won't work from the outside.
1:38 We also defined a method drive, we're overriding.
1:43 This one is a virtual, it has the ability to be
1:46 overridden, but we don't say virtual.
1:48 Basically, imagine everything is virtual in Python.
1:51 We have a property
1:53 we used a @property decorator to indicate
1:55 that this is meant to act like a computed value
1:58 not like a function. We also have an abstract method refuel
2:01 which we indicate with
2:02 the @abstractmethod decorator.
2:05 This is our base class.
2:06 If we are going to use it, we just derive from it.
2:09 class ElectricCar(Car).
2:11 Now we are deriving from it.
2:12 Here we create a
2:13 specialized, initialized initializer __init__
2:16 that takes only two values, model name and price
2:19 and then it calls the superclasses one
2:21 and always passes electric and zero
2:24 so you don't have to worry about that
2:25 when you use the ElectricCar.
2:26 It overrides drive, and it overrides
2:29 and must override, refuel.
2:31 On both of those, there is no key words around it.
2:34 You just do it, and it happens.
2:36 It's easy to forget, but you really need to call
2:38 super.__init__, there is no implicit
2:42 constructor chaining.
2:43 Like, if I just create a constructor
2:44 it's not going to automatically call the default constructor
2:48 the bass class, and it's bass class's default constructor.
2:51 And so on. So make sure you always remember to call the bass class
2:54 init in your initializer.
2:56 You saw that Pycharm helped out with that as well.
3:00 Overridden methods, you need no modifiers.
3:02 There's not like override and virtual
3:04 or anything like that.
3:05 But, as we saw, you must implement the abstract ones
3:08 or you cannot create an instance of this class.
3:10 It in itself will be effectively abstract as well.