How to get the most out of Python classes

There should only be one — and preferably only one — obvious way to do it”, says the Zen of Python. Yet there are areas where even seasoned programmers debate what the right or wrong way to do things is.

One of these areas is Python classes. Borrowed from Object-Oriented Programming, they’re quite beautiful constructs that you can expand and modify as you code.

The big problem is that classes can make your code more complicated than necessary, and make it harder to read and maintain. So when should you use classes, and when should you use standard functions instead?

This story is a deeper dive into the matter. So if you’re in a hurry, you can skip the following two sections and scroll right down to the sections When to use classes and When classes are a bad idea.

Python classes: the very basics

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Classes are objects that allow you to group data structures and procedures in one place. For example, imagine you’re writing a piece of code to organize the inventory of a clothes shop.

You could create a class that takes each item of clothing in the shop, and stores key quantities such as the type of clothing, and its color and size. We’ll add an option to add a price, too.

Now, we can define various instances of the class and keep them organized:

We would add these two lines without indent, after the definition of the class. This code will run, but it’s not doing very much. We can add a method to set the price directly underneath the __init__ function, within the class definition:

We could also add some routines to tell us the price, or to promote an item by reducing the price:

Now, we can add some calls of our methods after the lines where we’ve initialized the instances of the class:

If you need to add more routines, you can just put them in the class definition.

The nicest part of all of this is that you can add and delete as many objects as you like. Deleting an attribute goes like so:

And if you want to delete an entire object, you do like so:

All of this is neat, simple, and expandable. Try doing this implementation with standard functions, and you’ll probably have a lot more trouble dealing with it.

From a theoretical point of view, there are more reasons why Python classes are a beautiful concept in many situations.

Classes are amazing — in theory

Separation of concerns: giving every class its own job

If you’ve attended lectures in computer science, it’s pretty likely that you’ve stumbled across the principle of “separation of concerns”. It basically means that you split up your program into different sections that deal with different pieces of information.

Classes, by their nature, allow you to keep to that principle. In other words, when you set out writing a program and you’re thinking in terms of classes, you might be building a good architecture because you’re ensuring that each problem has its own place.

Decoupling: making maintenance easier

Thinking in classes not only helps you keep features separate, but also independent of one another. Not only does this keep things neat and tidy; it is also a lot easier for maintenance.

Say you found a bug in one class: you could fix that bug without worrying about the other classes because there is no connection between them. Likewise, you could add new features without fearing that you’ll get tangled up with other pieces of the software.

Implementation hiding: defining what programmers can and can’t use

By using classes, you’re ensuring that methods are only used on one set of data. This adds to the security of the code because you’re less likely to use functions where they don’t belong.

Encapsulation: changing the code but not the user experience

Storing data structures and methods together is also called encapsulation. Since all of this is hidden from the end user, this allows you to modify data structures and methods without compromising the user experience.

For example, you might have to build a method that is quite complex. The advantage of encapsulation is that a user doesn’t need to understand any of that complexity because they can use it like a black box.

It is completely possible to build black-box-functions without using classes. With classes, however, this type of functioning is practically ensured.

Inheritance: writing the DNA of a data structure

With classes, you only have to define a data structure once. When you define an instance of a class, that instance automatically inherits the given structure.

In addition, inheritance makes it quite easy to delete or modify pieces of an instance or the whole class. This makes the whole construct more flexible.

When to use classes

With so many advantages, it might be tempting to use a class for everything and anything. In practice, however, there are situations where using classes makes perfect sense, and others where it doesn’t.

Bunching data and methods together

As a rule of thumb, when you have a set of data with a specific structure and you want to perform specific methods on it, use a class. That is only valid, however, if you use multiple data structures in your code.

If your whole code won’t ever deal with more than one structure. If you only have one data structure, it really depends on the problem at hand. You can get a rough idea by sketching out your program with or without a class; usually you’ll see pretty soon which solution is simpler.

Beware of global variables

Another rule of thumb is this: If you’re tempted to use global variables to access data, it might be easier to define a class and build a method to access each piece of data.

Way easier than defining a new class!

When classes are a bad idea

Use heapq for heaps

A heap, unlike a stack, is a way of storing data in a more flexible way because it has unlimited memory size and allows you to resize variables. On the other hand, accessing variables is slower with a heap and you must manage the memory yourself.
If a heap suits your purposes better, you don’t need to define a class. Python’s inbuilt heapq, or heap queue algorithm, does the job for you.

Consider using functools.partial()

You might be tempted to use a class because you’re constantly calling a function with the same arguments. In most cases, it’s a better idea to use functools.partial() instead.

It’s quite simple to implement. Say you have a function that multiplies two values, but you keep using it to double values. To avoid duplicate code, you could write this:

Way easier than defining a new class!

Classes “for the future”

Some programmers get obsessed with classes because they’re so flexible and expandable. That’s why, even at reputable companies and seasoned developers, you might encounter code like this:

The idea behind it is that, as the code grows, this class might be needed for whichever new data structure and the methods that go with it. But this is not a good habit!

Guess what these three lines of code do? Exactly nothing. And those lines are not exactly difficult to code. If you think you’ll need another class later on, and you really think that you could forget about that in the future, you could always leave a comment like this:

The bottom line: Python classes are a two-edged sword

Classes are without doubt a powerful concept. Used correctly, they can make your code tidier, more readable, and maintainable.

But they get overused a lot. And when used wrongly, they can pollute your code until you understand nothing.

Sometimes, especially in simpler programs, you could use a class or a bunch of generic functions, and the code would be very similar in its length and complexity. As programs get more complex, the differences get more prominent.

In this sense, the Zen of Python has upheld its verdict: most of the time, there is indeed only one good way of doing things, whether that is with classes or without. It is, however, not always completely obvious. The difficult part is recognizing which way is the good one.

This article was written by Ari Joury and was originally published on Towards Data Science. You can read it here.