This article is a practical overview of Object Oriented Programming (OOP) in Python. It explains why OOP is useful, aside from how it’s done. This should be useful to both people who don’t know what OOP is, and experienced developers transitioning from other languages.

I am not a professional Python developer, and I am currently re-learning the language after not having used it for 8 years. So keep that in mind as you read, and feel free to offer feedback that can improve the quality of this article. Just be nice. 🙂

Due to the eternal divide between Python 2 and 3, I have to state that I’m using Python 3.6.4 here. Why Python 3? Because it makes no difference to me. When you are just learning and don’t have any requirements for maintaining backwards compatibility, you can afford to use the latest and greatest.

Introduction

In his hysterical rant on the web and OOP (in which he says the word “bizarre” enough times to qualify as a cover of OMC’s song), Zed Shaw cites OOP being “difficult to teach” as one of its major flaws.

Image credit: taken from here.

That’s a bold claim coming from someone who wrote in his own book:

“Search online for “object-oriented programming” and try to overflow your brain with what you read. Don’t worry if it makes absolutely no sense to you. Half of that stuff makes no sense to me either.” — Learn Python the Hard Way, Third Edition. Zed A. Shaw. 2014.

There are many things in computing that are hard to teach. I don’t think that Object Oriented Programming is one of them.

Motivation

In order to understand why OOP is useful, we’ll start off by not using it, and observe the problems we encounter. To do this, we need a proper example. People often teach OOP in terms of animals or cars, but I think games make more fun and interesting examples.

Screenshot from Dark Sun: Shattered Lands (1993)

A player-controlled character in a game typically has a number of attributes (e.g. name, hit points, etc). In order to group the attributes for our character, we need some kind of record or structure, which in C-style languages would be a struct. We don’t have that in Python, but we can use dictionaries instead.

talorus = {
    'name': 'Talorus',
    'hitpoints': 30,
    'dead': False,
    'inventory': []
}

Once we have a way to hold related data, we’ll want to perform some kind of operations on it.

def rename(character, newName):
    character['name'] = newName

def sufferDamage(character, damage):
    character['hitpoints'] -= damage
    if (character['hitpoints'] <= 0):
        character['dead'] = True

def receiveItem(character, item):
    character['inventory'].append(item)

Here’s some example usage:

You’ll notice a common theme across these functions. In all cases, we’re passing our character as the first parameter, and then using some of its attributes within the body of each function. We’re not using OOP yet, but we can already see a natural progression towards the character object being a first class citizen.

However, our current approach has a number of flaws. One of these is that it is easy for any code, anywhere, to tamper with our dictionary’s state.

Our logic from the sufferDamage() function specifies that characters die only if they run out of hitpoints, so how is our character dead with 26 hitpoints?

Being able to tamper with an object’s state without restriction is a bad thing: it is a violation of encapsulation, which is one of the three pillars of OOP (along with inheritance and polymorphism). We’ll discuss these later.

Classes and Objects

A class is just an abstract template for a type of object. For instance:

class Troll:
    pass

We’re declaring a Troll class, and using the pass keyword to indicate that there’s nothing in it for the time being. Once we have this class, then we can create concrete instances:

tom = Troll()
bert = Troll()
bill = Troll()

In Python, we create instances of a class (i.e. objects) by calling the class name as if it were a function.

An object may have any number of attributes (data members), just like the elements in a dictionary, but accessed using dot notation. Since Python is a dynamic language, it poses no restriction on the attributes that a class must have. We can add and remove attributes on the fly:

A class may define functions (called methods) that operate on an instance of the class:

class Character:

    def setName(self, newName):
        self.name = newName

This might look a bit weird, so let’s see some example usage and then discuss what we’re doing here:

The structure of the method might be familiar from the earlier section where we emulated OOP with dictionaries. In this case, we are similarly passing in the object itself as the first parameter, named self by convention. This extra parameter is required by Python. Through self, we can then access attributes of the class using dot notation.

What might look really strange here is that although setName() takes two parameters, we’re calling it with one. That’s because the self parameter is passed in implicitly when you call a method.

Constructors

A class may define a special method called __init__() which serves as the class’s constructor. It is usually used to initialise the object’s attributes, and may optionally take parameters which must be supplied when the object is instantiated:

class Character:

    def __init__(self, name, hitPoints):
        self.name = name
        self.hitPoints = hitPoints
        self.dead = False
        self.inventory = []

    def setName(self, newName):
        name = newName

Class-Level Variables

Screenshot from Ravenloft: Stone Prophet (1995)

A class may define variables within its scope:

class Monster:

    totalMonsters = 0

    def __init__(self, name, immortal):
        self.immortal = immortal
        Monster.totalMonsters += 1

Such class-level variables are not attributes of individual objects. They are shared across all instances of the class, just like static member variables in other languages. The distinction should be clear when you see that you access object attributes using self and class attributes using the name of the class itself. In this example, the shared totalMonsters counter is incremented every time a new monster is created:

Composition

Screenshot from Dark Sun: Shattered Lands (1993)

In the real world, complex objects are made up (composed) of other objects. The classic example is that a car has an engine (among other parts), but I prefer to stick to the game example. So let’s say we develop our inventory beyond a simple list, and make it into its own class:

class Inventory:

    def __init__(self):
        self.items = []

    def add(self, item):
        self.items.append(item)

    def has(self, item):
        return item in self.items

While this is a trivial implementation, it can be extended to support more complex operations.

We can now change our Character class to contain the new Inventory class:

class Character:

    def __init__(self, name, hitPoints):
        self.name = name
        self.hitPoints = hitPoints
        self.dead = False
        self.inventory = Inventory()

    def setName(self, newName):
        name = newName

Composition is used to model a has-a relationship (e.g. Character has an Inventory). As you can see, it’s nothing special. It’s merely a case of a class (e.g. Character) having an attribute whose type is also a class (e.g. Inventory).

Inheritance

Screenshot from Ultima 9: Ascension (1999)

A sword is a very common weapon in games. We can represent a simple sword by the following class:

class Sword:

    def __init__(self):
        self.damage = 10

    def attack(self, target):
        print('%d damage done to %s' % (self.damage, target))

Here’s an example usage:

However, there isn’t just one type of sword across all games in existence. Many games have magical swords with all sorts of positive (and negative) effects. One example is a fire sword. It does extra fire damage.

class FireSword:

    def __init__(self):
        self.damage = 10
        self.fireDamage = 5

    def attack(self, target):
        print('%d damage done to %s' % (self.damage, target))
        print('%d extra fire damage done to %s' % (self.fireDamage, target))

As you can see, there’s a lot of repetition here. If we also add classes for lightning swords, poison daggers etc, do we really want to duplicate this code and have to maintain it in several different places?

Fortunately, OOP allows us to create classes that inherit from others.

class FireSword (Sword):
    pass

The above code states that FireSword is-a Sword, and as a result, it inherits all of Sword‘s attributes and methods:

However, while we are reusing Sword‘s implementation for FireSword, we don’t yet have the extra functionality (i.e. extra fire damage) that makes it a fire sword, as we had in the original example. In order to do that, we must override Sword‘s methods to provide the extra functionality.

class FireSword (Sword):

    def __init__(self):
        super().__init__()
        self.fireDamage = 5

    def attack(self, target):
        super().attack(target)
        print('%d extra fire damage done to %s' % (self.fireDamage, target))

Here’s an example usage:

By calling super(), we’re calling the Sword class’s implementation before doing the extra logic specific to FireSword. In OOP terminology, Sword is the base class, parent class or superclass, and FireSword is the derived class or child class.

When you request an attribute or call a method on a derived class, Python will first look for an implementation in the derived class, and if it’s not there, it will look it up in the base class. This mechanism is what enables inheritance. However, it is also possible to have a method in the derived class to replace or extend the equivalent method in the base class, as we have seen above.

In other OOP languages, methods must usually be marked as virtual to allow them to be overridden. This is not necessary in Python.

“For C++ programmers: all methods in Python are effectively virtual.” — The Python Tutorial – Classes

Python allows a class to inherit from more than one base class. This is known as multiple inheritance, and is strongly discouraged because it makes classes extremely hard to work with. More modern OOP languages such as Java and C# expressly forbid multiple inheritance.

As a humorous aside, if you have a copy of Zed Shaw’s “Learn Python the Hard Way” book, you might want to read his section on “Inheritance vs Composition” for laughs. Shaw wastes almost a whole page with a silly story about a forest and an evil queen, which are supposed to be analogies for inheritance and multiple inheritance. His argument is that inheritance is bad because multiple inheritance is troublesome. That’s a bit like saying we should ban fire because some idiot got burned.

“In object-oriented programming, inheritance is the evil forest. Experienced programmers know to avoid this evil because they know that deep inside the dark forest of inheritance is the evil queen, multiple inheritance. She likes to eat software and programmers with her massive complexity teeth, chewing on the flesh of the fallen. But the forest is so powerful and so tempting that nearly every programmer has to go into it and try to make it out alive with the evil queen’s head before they can call themselves real programmers. You just can’t resist the inheritance forest’s pull, so you go in. After the adventure, you learn to just stay out of that stupid forest and bring an army if you are ever forced to go in again.” — Learn Python the Hard Way, Third Edition. Zed A. Shaw. 2014.

Shaw suggests that inheritance should be avoided, and composition should be used instead. For him, the choice between “inheritance versus composition comes down to an attempt to solve the problem of reusable code”. Unfortunately, he misses the point entirely. The main benefit of OOP is to model objects and their relationships. Inheritance models an is-a relationship, whereas composition models a has-a relationship. Code reuse is a practical benefit of both, but does not make them interchangeable.

Encapsulation

In the Motivation section towards the beginning of this article, we saw how emulating OOP with dictionaries results in a situation where the internal state of our classes can be tampered with. Let’s revisit that example, but with OOP:

class Character:

    def __init__(self, name, hitPoints):
        self.name = name
        self.hitPoints = hitPoints
        self.dead = False

    def sufferDamage(self, damage):
        self.hitPoints -= damage
        if (self.hitPoints <= 0):
            self.dead = True

Unfortunately, OOP in Python doesn’t do much to protect our internal state, and we can still tamper with it without restriction:

Other OOP languages usually have private, protected and public access modifiers to control access to internal data members of the class; these are enforced by the language. There is none of this in Python. The only thing you can do is follow a convention where private attributes are prefixed by an underscore, and hope that people play fair. It doesn’t stop people from accessing internal state.

Hiding the internal state of a class is called encapsulation. One strong reason why it is important is, as we’ve just seen, to ensure the consistency of that internal state (dead with 255 hit points? huh?). Another reason is to be able to modify the way that state works, without external code being affected.

So right now, we have an attribute called dead (or _dead, if we’re making it private by convention). Let’s add a method that exposes it:

class Character:

    def __init__(self, name, hitPoints):
        self._name = name
        self._hitPoints = hitPoints
        self._dead = False

    def sufferDamage(self, damage):
        self._hitPoints -= damage
        if (self._hitPoints <= 0):
            self._dead = True

    def isDead(self):
        return self._dead

Code external to this class may now check whether the character is dead by calling the isDead() method, and should not access _dead directly:

xanathar.isDead()

This extra method gives us a lot of flexibility because external code does not get to see how we store our internal state. We could, for instance, replace our _dead attribute with a computation based on _hitPoints, and the external code would never know the difference:

    def isDead(self):
        return self._hitPoints <= 0

So while in Python you can’t force external code not to touch a class’s internal state (as other OOP languages usually do), it is good practice to hide internal state using the available conventions, and expose only what needs to be exposed.

Polymorphism

Image credit: screenshot of Ultima 7: The Black Gate (1992) using Exult, taken from Let’s Play Archive entry

Typically, a person in a game can talk:

class Person:

    def Talk(self):
        print('Hello!')

Sometimes, though, an item can also talk.

class BlackSword:

    def Talk(self):
        print('Which of my powers dost thou seek to use?')

Animals, too, may surprise you with their gift of speech.

class SherryTheMouse:

    def Talk(self):
        print('Do you have any cheese?')

So here we have three completely unrelated classes, but they all have the same ability: we can call the Talk() method. When different objects exhibit similar behaviour, and thus we can work with them in a consistent manner, it’s called Polymorphism.

This is useful, for instance, when iterating over different kinds of objects in a loop:

This is unusual in the world of OOP, but since Python uses duck typing, it’s enough that two classes have the same method signature so that you can use them in the same way. In more strongly-typed OOP languages such as C# or Java, the classes would need to have something in common for you to do this (e.g. they implement the same interface, or they share a common base class).

Generics

This section is for developers coming from OOP in other languages. If you’re new to OOP, you may skip it.

Sometimes, you want to make a class have the same behaviour with different data types. For instance, you create a class representing a stack, and it should work the same regardless of whether it’s a stack of integers or of strings.

C++ provides this through templates, and C# and Java provide generics. These are a way to generalise the class implementation across dependent types, while still enforcing type safety.

Since Python is a dynamic language and it does not care what types you use, generics are not necessary. Your stack (or whatever) class will work just as will with integers, strings, or Animals (although I don’t recommend putting elephants at the top of the stack).

Summary

In this article, we’ve covered the basics of OOP in Python.

• Even if you’re not currently doing OOP, you’ll notice that groups of variables and functions will tend to relate to the same entity. There is a natural tendency towards OOP.
• Classes are groups of attributes and functions (methods). They provide a template but are not concrete.
• Objects are concrete instances of classes. Person is a class. Joe is an object.
• A constructor allows you to initialise attributes and pass in any parameters at instantiation time.
• Class-level variables are shared across all instances of that class.
• Composition is when a class contains other classes. It expresses a has-a relationship.
• Inheritance expresses an is-a relationship. If FireSword is-a Sword, then FireSword inherits all of Sword’s attributes and methods, and may override those methods to provide more specialised variants.
• Encapsulation is hiding internal attributes of a class so that external code can’t change them, and so that internal code can be changed without affecting external code. This is not enforced by the language but is upheld by convention.
• Polymorphism is when different objects behave in a similar way. In Python, it works as a result of duck typing.
• Generics aren’t necessary in a language without type safety.

This material includes basic concepts and language syntax, but is merely a starting point.

Mastering OOP is a matter of understanding that it is all about abstraction, and learning to work with abstractions in a way that is beneficial to software (e.g. models problem domains, maximises code reuse, reduces coupling, increases maintainability etc). The three pillars of OOP (inheritance, encapsulation and polymorphism) are basic building blocks of such abstraction. Various design patterns have emerged which demonstrate OOP abstractions put to good use.