Improve Your Python: Python Classes and Object Oriented Programming

**Note: Each day this week I’m going to republish one of my most popular posts. My hope is that people who missed them the first time might find them useful now. This post, on “classes” and Object Oriented Programming remains my most popular post of all time. I’ve gotten hundreds of emails about this post alone. Many have found it an accessible introduction to classes and OOP, both in Python and in general.** The `class` is a fundamental building block in [Python](https://hackernoon.com/tagged/python). It is the underpinning for not only many popular programs and libraries, but the Python standard library as well. Understanding what classes are, when to use them, and how they can be useful is essential, and the goal of this article. In the process, we'll explore what the term _Object-Oriented_ [_Programming_](https://hackernoon.com/tagged/programming) means and how it ties together with Python classes. ### Everything Is An Object… What is the `class` keyword used for, exactly? Like its function-based cousin `def`, it concerns the _definition_ of things. While `def` is used to define a function, `class` is used to define a _class_. And what is a class? Simply a logical grouping of data and functions (the latter of which are frequently referred to as "methods" when defined within a class). What do we mean by “logical grouping”? Well, a class can contain any data we’d like it to, and can have any functions (methods) attached to it that we please. Rather than just throwing random things together under the name “class”, we try to create classes where there is a logical connection between things. Many times, classes are based on objects in the real world (like `Customer` or `Product`). Other times, classes are based on concepts in our system, like `HTTPRequest` or `Owner`. Regardless, classes are a _modeling_ technique; a way of thinking about programs. When you think about and implement your system in this way, you’re said to be performing _Object-Oriented Programming_. “Classes” and “objects” are words that are often used interchangeably, but they’re not really the same thing. Understanding what makes them different is the key to understanding what they are and how they work. ### ..So Everything Has A Class? Classes can be thought of as _blueprints for creating objects_. When I _define_ a Customer class using the `class` keyword, I haven't actually created a customer. Instead, what I've created is a sort of instruction manual for constructing "customer" objects. Let's look at the following example code: **class** **Customer**(object): _"""A customer of ABC Bank with a checking account. Customers have the_ _following properties:_ _Attributes:_ _name: A string representing the customer's name._ _balance: A float tracking the current balance of the customer's account._ _"""_ **def** \_\_init\_\_(self, name, balance=0.0): _"""Return a Customer object whose name is \*name\* and starting_ _balance is \*balance\*."""_ self.name = name self.balance = balance **def** withdraw(self, amount): _"""Return the balance remaining after withdrawing \*amount\*_ _dollars."""_ **if** amount > self.balance: **raise** **RuntimeError**('Amount greater than available balance.') self.balance -= amount **return** self.balance **def** deposit(self, amount): _"""Return the balance remaining after depositing \*amount\*_ _dollars."""_ self.balance += amount **return** self.balance The `class Customer(object)` line _does not_ create a new customer. That is, just because we've _defined_ a `Customer` doesn't mean we've _created_ one; we've merely outlined the _blueprint_ to create a `Customer` object. To do so, we call the class's `__init__` method with the proper number of arguments (minus `self`, which we'll get to in a moment). So, to use the “blueprint” that we created by defining the `class Customer` (which is used to create `Customer` objects), we call the class name almost as if it were a function: `jeff = Customer('Jeff Knupp', 1000.0)`. This line simply says "use the `Customer` blueprint to create me a new object, which I'll refer to as `jeff`." The `jeff` _object_, known as an _instance_, is the realized version of the `Customer` _class_. Before we called `Customer()`, no `Customer` object existed. We can, of course, create as many `Customer` objects as we'd like. There is still, however, only one `Customer` _class_, regardless of how many _instances_ of the class we create. ### `self`? So what’s with that `self` parameter to all of the `Customer` methods? What is it? Why, it's the instance, of course! Put another way, a method like `withdraw` defines the instructions for withdrawing money from _some abstract customer's account_. Calling `jeff.withdraw(100.0)` puts those instructions to use _on the_ `_jeff_` _instance_. So when we say `def withdraw(self, amount):`, we're saying, "here's how you withdraw money from a Customer object (which we'll call `self`) and a dollar figure (which we'll call `amount`). `self` is the _instance_ of the `Customer` that `withdraw` is being called on. That's not me making analogies, either. `jeff.withdraw(100.0)` is just shorthand for `Customer.withdraw(jeff, 100.0)`, which is perfectly valid (if not often seen) code. ### `__init__` `self` may make sense for other methods, but what about `__init__`? When we call `__init__`, we're in the process of creating an object, so how can there already be a `self`? Python allows us to extend the `self` pattern to when objects are constructed as well, even though it doesn't _exactly_ fit. Just imagine that `jeff = Customer('Jeff Knupp', 1000.0)` is the same as calling `jeff = Customer(jeff, 'Jeff Knupp', 1000.0)`; the `jeff` that's passed in is also made the result. This is why when we call `__init__`, we _initialize_ objects by saying things like `self.name = name`. Remember, since `self` _is_ the instance, this is equivalent to saying `jeff.name = name`, which is the same as `jeff.name = 'Jeff Knupp`. Similarly, `self.balance = balance` is the same as `jeff.balance = 1000.0`. After these two lines, we consider the `Customer` object "initialized" and ready for use. #### Be careful what you `__init__` After `__init__` has finished, the caller can rightly assume that the object is ready to use. That is, after `jeff = Customer('Jeff Knupp', 1000.0)`, we can start making `deposit` and `withdraw` calls on `jeff`; `jeff` is a **fully-initialized** object. Imagine for a moment we had defined the `Customer` class slightly differently: **class** **Customer**(object): _"""A customer of ABC Bank with a checking account. Customers have the_ _following properties:_ _Attributes:_ _name: A string representing the customer's name._ _balance: A float tracking the current balance of the customer's account._ _"""_ **def** \_\_init\_\_(self, name): _"""Return a Customer object whose name is \*name\*."""_ self.name = name **def** set\_balance(self, balance=0.0): _"""Set the customer's starting balance."""_ self.balance = balance **def** withdraw(self, amount): _"""Return the balance remaining after withdrawing \*amount\*_ _dollars."""_ **if** amount > self.balance: **raise** **RuntimeError**('Amount greater than available balance.') self.balance -= amount **return** self.balance **def** deposit(self, amount): _"""Return the balance remaining after depositing \*amount\*_ _dollars."""_ self.balance += amount **return** self.balance This may look like a reasonable alternative; we simply need to call `set_balance` before we begin using the instance. There's no way, however, to communicate this to the caller. Even if we document it extensively, we can't _force_ the caller to call `jeff.set_balance(1000.0)` before calling `jeff.withdraw(100.0)`. Since the `jeff` instance doesn't even _have_ a balance attribute until `jeff.set_balance` is called, this means that the object hasn't been "fully" initialized. The rule of thumb is, don’t _introduce_ a new attribute outside of the `__init__` method, otherwise you've given the caller an object that isn't fully initialized. There are exceptions, of course, but it's a good principle to keep in mind. This is part of a larger concept of object _consistency_: there shouldn't be any series of method calls that can result in the object entering a state that doesn't make sense. Invariants (like, “balance should always be a non-negative number”) should hold both when a method is entered and when it is exited. It should be impossible for an object to get into an invalid state just by calling its methods. It goes without saying, then, that an object should _start_ in a valid state as well, which is why it’s important to initialize everything in the `__init__` method. ### Instance Attributes and Methods An function defined in a class is called a “method”. Methods have access to all the data contained on the instance of the object; they can access and modify anything previously set on `self`. Because they use `self`, they require an instance of the class in order to be used. For this reason, they're often referred to as "instance methods". If there are “instance methods”, then surely there are other types of methods as well, right? Yes, there are, but these methods are a bit more esoteric. We’ll cover them briefly here, but feel free to research these topics in more depth. ### Static Methods _Class attributes_ are attributes that are set at the _class-level_, as opposed to the _instance-level_. Normal attributes are introduced in the `__init__` method, but some attributes of a class hold for _all_ instances in all cases. For example, consider the following definition of a `Car` object: **class** **Car**(object): wheels = 4 **def** \_\_init\_\_(self, make, model): self.make = make self.model = model mustang = Car('Ford', 'Mustang') **print** mustang.wheels _\# 4_ **print** Car.wheels _\# 4_ A `Car` always has four `wheels`, regardless of the `make` or `model`. Instance methods can access these attributes in the same way they access regular attributes: through `self` (i.e. `self.wheels`). There is a class of methods, though, called _static methods_, that don’t have access to `self`. Just like class attributes, they are methods that work without requiring an instance to be present. Since instances are always referenced through `self`, static methods have no `self` parameter. The following would be a valid static method on the `Car` class: **class** **Car**(object): ... **def** make\_car\_sound(): **print** 'VRooooommmm!' No matter what kind of car we have, it always makes the same sound (or so I tell my ten month old daughter). To make it clear that this method should not receive the instance as the first parameter (i.e. `self` on "normal" methods), the `@staticmethod` decorator is used, turning our definition into: **class** **Car**(object): ... @staticmethod **def** make\_car\_sound(): **print** 'VRooooommmm!' ### Class Methods A variant of the static method is the _class method_. Instead of receiving the _instance_ as the first parameter, it is passed the _class_. It, too, is defined using a decorator: **class** **Vehicle**(object): ... @classmethod **def** is\_motorcycle(cls): **return** cls.wheels == 2 Class methods may not make much sense right now, but that’s because they’re used most often in connection with our next topic: _inheritance_. ### Inheritance While Object-oriented Programming is useful as a modeling tool, it truly gains power when the concept of _inheritance_ is introduced. _Inheritance_ is the process by which a “child” class _derives_ the data and behavior of a “parent” class. An example will definitely help us here. Imagine we run a car dealership. We sell all types of vehicles, from motorcycles to trucks. We set ourselves apart from the competition by our prices. Specifically, how we determine the price of a vehicle on our lot: $5,000 x number of wheels a vehicle has. We love buying back our vehicles as well. We offer a flat rate — 10% of the miles driven on the vehicle. For trucks, that rate is $10,000. For cars, $8,000. For motorcycles, $4,000. If we wanted to create a sales system for our dealership using Object-oriented techniques, how would we do so? What would the objects be? We might have a `Sale` class, a `Customer` class, an `Inventory` class, and so forth, but we'd almost certainly have a `Car`, `Truck`, and `Motorcycle` class. What would these classes look like? Using what we’ve learned, here’s a possible implementation of the `Car` class: **class** **Car**(object): _"""A car for sale by Jeffco Car Dealership._ _Attributes:_ _wheels: An integer representing the number of wheels the car has._ _miles: The integral number of miles driven on the car._ _make: The make of the car as a string._ _model: The model of the car as a string._ _year: The integral year the car was built._ _sold\_on: The date the vehicle was sold._ _"""_ **def** \_\_init\_\_(self, wheels, miles, make, model, year, sold\_on): _"""Return a new Car object."""_ self.wheels = wheels self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on **def** sale\_price(self): _"""Return the sale price for this car as a float amount."""_ **if** self.sold\_on **is** **not** None: **return** 0.0 _\# Already sold_ **return** 5000.0 \* self.wheels **def** purchase\_price(self): _"""Return the price for which we would pay to purchase the car."""_ **if** self.sold\_on **is** None: **return** 0.0 _\# Not yet sold_ **return** 8000 - (.10 \* self.miles) ... OK, that looks pretty reasonable. Of course, we would likely have a number of other methods on the class, but I’ve shown two of particular interest to us: `sale_price` and `purchase_price`. We'll see why these are important in a bit. Now that we’ve got the `Car` class, perhaps we should crate a `Truck` class? Let's follow the same pattern we did for car: **class** **Truck**(object): _"""A truck for sale by Jeffco Car Dealership._ _Attributes:_ _wheels: An integer representing the number of wheels the truck has._ _miles: The integral number of miles driven on the truck._ _make: The make of the truck as a string._ _model: The model of the truck as a string._ _year: The integral year the truck was built._ _sold\_on: The date the vehicle was sold._ _"""_ **def** \_\_init\_\_(self, wheels, miles, make, model, year, sold\_on): _"""Return a new Truck object."""_ self.wheels = wheels self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on **def** sale\_price(self): _"""Return the sale price for this truck as a float amount."""_ **if** self.sold\_on **is** **not** None: **return** 0.0 _\# Already sold_ **return** 5000.0 \* self.wheels **def** purchase\_price(self): _"""Return the price for which we would pay to purchase the truck."""_ **if** self.sold\_on **is** None: **return** 0.0 _\# Not yet sold_ **return** 10000 - (.10 \* self.miles) ... Wow. That’s _almost identical_ to the car class. One of the most important rules of programming (in general, not just when dealing with objects) is “DRY” or “**D**on’t **R**epeat **Y**ourself. We’ve definitely repeated ourselves here. In fact, the `Car` and `Truck` classes differ only by _a single character_ (aside from comments). So what gives? Where did we go wrong? Our main problem is that we raced straight to the concrete: `Car`s and `Truck`s are real things, tangible objects that make intuitive sense as classes. However, they share so much data and functionality in common that it seems there must be an _abstraction_ we can introduce here. Indeed there is: the notion of `Vehicle`s. ### Abstract Classes A `Vehicle` is not a real-world object. Rather, it is a _concept_ that some real-world objects (like cars, trucks, and motorcycles) embody. We would like to use the fact that each of these objects can be considered a vehicle to remove repeated code. We can do that by creating a `Vehicle` class: class Vehicle(object): """A vehicle for sale by Jeffco Car Dealership. Attributes: wheels: An integer representing the number of wheels the vehicle has. miles: The integral number of miles driven on the vehicle. make: The make of the vehicle as a string. model: The model of the vehicle as a string. year: The integral year the vehicle was built. sold\_on: The date the vehicle was sold. """ base\_sale\_price = 0 def \_\_init\_\_(self, wheels, miles, make, model, year, sold\_on): """Return a new Vehicle object.""" self.wheels = wheels self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on def sale\_price(self): """Return the sale price for this vehicle as a float amount.""" **if** self.sold\_on is not None: **return** 0.0 # Already sold **return** 5000.0 \* self.wheels def purchase\_price(self): """Return the price for which we would pay to purchase the vehicle.""" **if** self.sold\_on is None: **return** 0.0 # Not yet sold **return** self.base\_sale\_price - (.10 \* self.miles) Now we can make the `Car` and `Truck` class _inherit_ from the `Vehicle` class by replacing `object` in the line `class Car(object)`. The class in parenthesis is the class that is inherited from (`object` essentially means "no inheritance". We'll discuss exactly why we write that in a bit). We can now define `Car` and `Truck` in a very straightforward way: **class** **Car**(Vehicle): **def** \_\_init\_\_(self, wheels, miles, make, model, year, sold\_on): _"""Return a new Car object."""_ self.wheels = wheels self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on self.base\_sale\_price = 8000 **class** **Truck**(Vehicle): **def** \_\_init\_\_(self, wheels, miles, make, model, year, sold\_on): _"""Return a new Truck object."""_ self.wheels = wheels self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on self.base\_sale\_price = 10000 This works, but has a few problems. First, we’re still repeating a lot of code. We’d ultimately like to get rid of **all** repetition. Second, and more problematically, we’ve introduced the `Vehicle` class, but should we really allow people to create `Vehicle` objects (as opposed to `Car`s or `Truck`s)? A `Vehicle` is just a concept, not a real thing, so what does it mean to say the following: v = Vehicle(4, 0, 'Honda', 'Accord', 2014, None) print v.purchase\_price() A `Vehicle` doesn't have a `base_sale_price`, only the individual _child_ classes like `Car` and `Truck` do. The issue is that `Vehicle` should really be an _Abstract Base Class_. Abstract Base Classes are classes that are only meant to be inherited from; you can't create _instance_ of an ABC. That means that, if `Vehicle` is an ABC, the following is illegal: v = Vehicle(4, 0, 'Honda', 'Accord', 2014, None) It makes sense to disallow this, as we never meant for vehicles to be used directly. We just wanted to use it to abstract away some common data and behavior. So how do we make a class an ABC? Simple! The `abc` module contains a metaclass called `ABCMeta` (metaclasses are a bit outside the scope of this article). Setting a class's metaclass to `ABCMeta` and making one of its methods _virtual_ makes it an ABC. A _virtual_ method is one that the ABC says must exist in child classes, but doesn't necessarily actually implement. For example, the Vehicle class may be defined as follows: **from** **abc** **import** ABCMeta, abstractmethod **class** **Vehicle**(object): _"""A vehicle for sale by Jeffco Car Dealership._ _Attributes:_ _wheels: An integer representing the number of wheels the vehicle has._ _miles: The integral number of miles driven on the vehicle._ _make: The make of the vehicle as a string._ _model: The model of the vehicle as a string._ _year: The integral year the vehicle was built._ _sold\_on: The date the vehicle was sold._ _"""_ \_\_metaclass\_\_ = ABCMeta base\_sale\_price = 0 **def** sale\_price(self): _"""Return the sale price for this vehicle as a float amount."""_ **if** self.sold\_on **is** **not** None: **return** 0.0 _\# Already sold_ **return** 5000.0 \* self.wheels **def** purchase\_price(self): _"""Return the price for which we would pay to purchase the vehicle."""_ **if** self.sold\_on **is** None: **return** 0.0 _\# Not yet sold_ **return** self.base\_sale\_price - (.10 \* self.miles) @abstractmethod **def** vehicle\_type(): _""""Return a string representing the type of vehicle this is."""_ **pass** Now, since `vehicle_type` is an `abstractmethod`, we can't directly create an instance of `Vehicle`. As long as `Car` and `Truck` inherit from `Vehicle` **and** define `vehicle_type`, we can instantiate those classes just fine. Returning to the repetition in our `Car` and `Truck` classes, let see if we can't remove that by hoisting up common functionality to the base class, `Vehicle`: **from** **abc** **import** ABCMeta, abstractmethod **class** **Vehicle**(object): _"""A vehicle for sale by Jeffco Car Dealership._ _Attributes:_ _wheels: An integer representing the number of wheels the vehicle has._ _miles: The integral number of miles driven on the vehicle._ _make: The make of the vehicle as a string._ _model: The model of the vehicle as a string._ _year: The integral year the vehicle was built._ _sold\_on: The date the vehicle was sold._ _"""_ \_\_metaclass\_\_ = ABCMeta base\_sale\_price = 0 wheels = 0 **def** \_\_init\_\_(self, miles, make, model, year, sold\_on): self.miles = miles self.make = make self.model = model self.year = year self.sold\_on = sold\_on **def** sale\_price(self): _"""Return the sale price for this vehicle as a float amount."""_ **if** self.sold\_on **is** **not** None: **return** 0.0 _\# Already sold_ **return** 5000.0 \* self.wheels **def** purchase\_price(self): _"""Return the price for which we would pay to purchase the vehicle."""_ **if** self.sold\_on **is** None: **return** 0.0 _\# Not yet sold_ **return** self.base\_sale\_price - (.10 \* self.miles) @abstractmethod **def** vehicle\_type(self): _""""Return a string representing the type of vehicle this is."""_ **pass** Now the `Car` and `Truck` classes become: **class** **Car**(Vehicle): _"""A car for sale by Jeffco Car Dealership."""_ base\_sale\_price = 8000 wheels = 4 **def** vehicle\_type(self): _""""Return a string representing the type of vehicle this is."""_ **return** 'car' **class** **Truck**(Vehicle): _"""A truck for sale by Jeffco Car Dealership."""_ base\_sale\_price = 10000 wheels = 4 **def** vehicle\_type(self): _""""Return a string representing the type of vehicle this is."""_ **return** 'truck' This fits perfectly with our intuition: as far as our system is concerned, the only difference between a car and truck is the base sale price. Defining a `Motorcycle` class, then, is similarly simple: **class** **Motorcycle**(Vehicle): _"""A motorcycle for sale by Jeffco Car Dealership."""_ base\_sale\_price = 4000 wheels = 2 **def** vehicle\_type(self): _""""Return a string representing the type of vehicle this is."""_ **return** 'motorcycle' ### Inheritance and the LSP Even though it seems like we used inheritance to get rid of duplication, what we were _really_ doing was simply providing the proper level of abstraction. And _abstraction_ is the key to understanding inheritance. We’ve seen how one side-effect of using inheritance is that we reduce duplicated code, but what about from the _caller’s perspective_. How does using inheritance change that code? Quite a bit, it turns out. Imagine we have two classes, `Dog` and `Person`, and we want to write a function that takes either type of object and prints out whether or not the instance in question can speak (a dog can't, a person can). We might write code like the following: **def** can\_speak(animal): **if** isinstance(animal, Person): **return** True **elif** isinstance(animal, Dog): **return** False **else**: **raise** **RuntimeError**('Unknown animal!') That works when we only have two types of animals, but what if we have twenty, or _two hundred_? That `if...elif` chain is going to get quite long. The key insight here is that `can_speak` shouldn't care what type of animal it's dealing with, the animal class itself should tell _us_ if it can speak. By introducing a common base class, `Animal`, that defines `can_speak`, we relieve the function of it's type-checking burden. Now, as long as it knows it was an `Animal` that was passed in, determining if it can speak is trivial: **def** can\_speak(animal): **return** animal.can\_speak() This works because `Person` and `Dog` (and whatever other classes we crate to derive from `Animal`) follow the _Liskov Substitution Principle_. This states that we should be able to use a child class (like `Person` or `Dog`) wherever a parent class (`Animal`) is expected an everything will work fine. This sounds simple, but it is the basis for a powerful concept we'll discuss in a future article: _interfaces_. ### Summary Hopefully, you’ve learned a lot about what Python classes are, why they’re useful, and how to use them. The topic of classes and Object-oriented Programming are insanely deep. Indeed, they reach to the core of computer science. This article is not meant to be an exhaustive study of classes, nor should it be your only reference. There are literally thousands of explanations of OOP and classes available online, so if you didn’t find this one suitable, certainly a bit of searching will reveal one better suited to you. As always, corrections and arguments are welcome in the comments. Just try to keep it civil. Posted on Mar 27, 2017 by Jeff Knupp _Originally published at_ [_jeffknupp.com_](https://jeffknupp.com/blog/2017/03/27/improve-your-python-python-classes-and-object-oriented-programming/) _on March 27, 2017._ > [Hacker Noon](http://bit.ly/Hackernoon) is how hackers start their afternoons. We’re a part of the [@AMI](http://bit.ly/atAMIatAMI)family. We are now [accepting submissions](http://bit.ly/hackernoonsubmission) and happy to [discuss advertising & sponsorship](mailto:partners@amipublications.com) opportunities. > To learn more, [read our about page](https://goo.gl/4ofytp), [like/message us on Facebook](http://bit.ly/HackernoonFB), or simply, [tweet/DM @HackerNoon.](https://goo.gl/k7XYbx) > If you enjoyed this story, we recommend reading our [latest tech stories](http://bit.ly/hackernoonlatestt) and [trending tech stories](https://hackernoon.com/trending). Until next time, don’t take the realities of the world for granted!

Improve Your Python: Python Classes and Object Oriented Programming

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Coin Mentioned

@jeffknupp

RELATED STORIES