Join Patrice Roy — ISO C++ Standards Committee member and author of C++ Memory Management — for a 2-day live masterclass on writing safe, efficient, and robust C++ code.

What you’ll learn (hands-on):

✔Smart pointers and RAII for predictable ownership

✔Exception-safe, high-performance techniques

✔Debugging leaks, alignment, and ownership issues

✔Building memory-safe code that performs under pressure

Patrice has taught C++ since 1998, trained professional programmers for over 20 years, and speaks regularly at CppCon. This masterclass distills his experience into practical skills you can apply immediately in production.

Use code DEEPENG30 for 30% off.

Hi

Welcome to the fifteenth issue of Deep Engineering.

In most systems, data outlives code; object orientation is one disciplined way to model it.

In this issue, we zoom in on object oriented programming (OOP) through the lense of pragmatic Python practice—how to move from a blank screen to working types, when a class earns its keep, and how to avoid boilerplate while keeping invariants intact. These choices have a significant impact in production: clearer models reduce duplication, make change cheaper, and keep behavior close to the state it governs.

For this issue, we’ve collaborated with Steven F. Lott who has been programming since computers were large, expensive, and rare. Since the 1990s, Steven has been engaged with Python, crafting an array of indispensable tools and applications. He is also the author of notable titles like Mastering Object-Oriented Python (Packt, 2019), Modern Python Cookbook (Packt, 2024), and Python Real-World Projects (Packt, 2023). Lott is currently working on the 5th Ed. of Python Object-Oriented Programming due later this year.

What’s inside:

Let’s get started.

📢 Important: Deep Engineering is Moving to Substack

Next week, we’ll be shifting Deep Engineering fully to Substack. From the 4th of September 2025, all issues will come from [email protected].

To ensure uninterrupted delivery, please whitelist this address in your mail client. No other action is required.

You’ll continue receiving the newsletter on the same weekly cadence, and on Substack you’ll also gain access to more expert led content and more granular control over preferences if you wish to adjust them later.

Sign Up |Advertise

One of the hardest parts of adopting object-oriented programming (OOP) is figuring out where to start. The blank screen can be intimidating, especially after working through neatly packaged tutorials. A practical first step is focusing on the data your program will manage. Before diving into class hierarchies, sketch out what information you need to represent and how that data will be used. For example, if you’re modeling a card game, start by listing basic elements like cards, decks, and hands, along with their attributes (rank, suit, etc.). This data-first strategy reflects a fundamental truth: in a software project, the data outlives the code interface. UIs, scripts, and functions can change, but the core information (files, databases) usually persists.

In Python, a convenient way to quickly translate a data outline into code is to use the @dataclass decorator. A dataclass automatically generates an initializer and other useful methods from a simple class definition of attributes and type hints. This allows you to prototype classes rapidly without writing boilerplate. For instance, if we’re modeling playing cards, we can start simple:

from dataclasses import dataclass

@dataclass
class Card:
rank: int
suit: str

This snippet defines a basic Card class with two attributes. Python’s naming conventions suggest using CapitalizedWord for class names (sometimes called PascalCase) and lowercase with underscores for attribute names. Don’t agonize over getting the design perfect on the first try – treat these initial classes as throwaways or drafts. The goal is to get something working in code to avoid analysis paralysis. As Lott puts it, there’s “no royal road” to mastering OOP – you learn by building, testing, and iterating.

With preliminary classes in place, start experimenting with usage to validate your design. Write small functions or scripts to create objects and exercise their behavior. Continuing our card game example, we might generate a deck of cards and print them out to see if the output makes sense. This often reveals design flaws or missing pieces. In our initial Card class above, printing a card would yield an output like Card(rank=7, suit='♢'), which is informative but not very user-friendly. We can improve this by adding a custom __str__ method for pretty-printing:

def __str__(self) -> str:
names = {1: "A", 11: "J", 12: "Q", 13: "K"}
rank_display = names.get(self.rank, str(self.rank))
return f"{rank_display:>2s}{self.suit}"

Now a print(card) will display a nicely formatted string like J♠ instead of a verbose dataclass representation. This kind of refinement aligns with the Interface Segregation Principle: each class should present a clear and minimal interface to collaborators. By encapsulating display logic inside Card.__str__, we free other parts of the program (like a Deck or Hand class) from knowing the formatting details.

Another common discovery during iteration is the need to move functionality into the class to encapsulate behavior with data. In our card example, we might have initially computed point values for cards (say, face cards count as 10 points) outside the class. If that calculation is always the same, it belongs in the class definition. One elegant way to do this in Python is with the @property decorator, which lets you define a method that looks like a regular attribute when accessed:

from dataclasses import dataclass

@dataclass
class Card:
rank: int
suit: str

@property
def points(self) -> int:
return 10 if self.rank >= 11 else self.rank

Here, Card.points is defined as a property that derives the point value from the rank. Now other code can simply use card.points instead of calling a method or doing the logic externally. This improves encapsulation and readability – the card “knows” how many points it’s worth, and the rest of the program doesn’t need to duplicate that logic or remember the rule.

As you flesh out the classes, be prepared to add or split classes to narrow their responsibilities. In our card game, we treated a hand of cards as a simple list (List[Card]) at first. But if we find ourselves writing a lot of code to manipulate or display hands (sorting, pretty-printing collections of cards, etc.), that’s a sign we need a Hand class. It might start as simple as:

from dataclasses import dataclass

@dataclass
class Hand:
cards: list[Card]

def __str__(self) -> str:
return ', '.join(str(c) for c in self.cards)

This Hand class wraps a list of Card objects and provides its own __str__ to print the hand neatly. By refactoring in this way (sometimes called composition – a hand is composed of cards), we reduce duplication and make the code more expressive. The overarching lesson is to evolve your design iteratively: get something working, review it, and refactor when an object’s responsibilities start getting tangled or stretched.

Python gives you many ways to represent data and behavior. Not everything needs to be a class. A key skill in OOP (and a theme of Lott & Phillips’ discussion in Python Object-Oriented Programming) is knowing when a class is warranted. A good rule of thumb: use classes when you have a bundle of state and related behavior that benefit from being encapsulated together. If you have data with no behaviors, a simple tuple, list, or dictionary might do. If you have behavior with no state (just input-output transformation), a standalone function could be clearer.

For example, to compute the perimeter of a polygon, you could store the vertices as a list of coordinate pairs (tuples) and write a function perimeter(polygon) that calculates the sum of distances. This functional approach is concise:

from math import hypot

# polygon represented as list of (x, y) points
square = [(1, 1), (1, 2), (2, 2), (2, 1)]

def distance(p1, p2):
return hypot(p1[0] - p2[0], p1[1] - p2[1])

def perimeter(poly):
return sum(distance(p1, p2) for p1, p2 in zip(poly, poly[1:] + poly[:1]))

print(perimeter(square)) # 4.0

Here, using a class might actually complicate things – a simple data structure plus function is sufficiently clear. On the other hand, if we need to support many operations on polygons (area, moving/scaling, checking convexity, etc.), wrapping data and methods into a Polygon class starts to pay off. The class can hold the list of points and provide multiple methods (perimeter, area, etc.), keeping all polygon-related logic in one place. The number of related operations and the importance of invariants (like ensuring the polygon is always closed) factor into the decision. As a general principle, start simple with Python’s built-in types; introduce custom classes when they make the code more understandable or maintainable. Remember that code length isn’t the ultimate measure – sometimes a few extra lines in a class definition greatly improve clarity, as long as you’re not writing needless boilerplate.

Developers coming from other languages often follow a rigid getter/setter protocol for every attribute. In Python, this is usually unnecessary. You can expose attributes directly and only intervene when needed. Python’s philosophy is that “we’re all adults here” – if someone accesses a variable prefixed with _ (by convention meaning “internal use”), they should know what they’re doing. Instead of writing verbose get_foo() and set_foo() methods for each attribute, Python encourages the use of @property to manage access gracefully when requirements evolve.

Suppose we have a Color class with an RGB code and a name. Initially, direct access is fine:

class Color:
def __init__(self, rgb_value: int, name: str) -> None:
self.rgb_value = rgb_value
self.name = name

If later we decide to enforce that name cannot be empty, we can convert name into a property without changing the external interface:

class Color:
def __init__(self, rgb_value: int, name: str) -> None:
self._rgb_value = rgb_value
self._name = name # underscore to indicate internal

@property
def name(self) -> str:
return self._name

@name.setter
def name(self, new_name: str) -> None:
if not new_name:
raise ValueError("Color name cannot be empty")
self._name = new_name

Client code that uses c = Color(0xff0000, "red") and then c.name or c.name = "crimson" will continue to work, but now with validation. The ability to retrofit logic with properties helps maintain encapsulation without imposing a clunky API from the start. Use methods for actions (verbs) and use attributes/properties for state (nouns/adjectives). This keeps your code Pythonic and clear. Properties are also handy for lazy computations or caching. For instance, you might fetch and cache a web page’s content on first access, then reuse it on subsequent accesses – all behind the scenes of a content property so that calling code isn’t aware of the caching mechanism.

A major promise of OOP is reducing code repetition by abstracting common functionality. If you find yourself copying and pasting code, take a step back – could that logic live in a class (or base class) instead? For example, imagine we write a utility to find and replace text in all files within a ZIP archive. We might start with a script or class ZipReplace that unzips a file, performs replacements on each text file, and zips it back up. Later, we realize we need a similar tool to, say, resize all images in a ZIP. Rather than duplicating the unzip/iterate/zip logic, we can refactor the common parts into a general framework class (let’s call it ZipProcessor) and have specialized subclasses or hooks for the specific transformation (text replace or image resize).

Lott demonstrates this pattern by turning a specific ZipReplace class into a more flexible processor that accepts any operation. The key steps were:

Whether you choose inheritance (subclass and override a method) or composition (pass in a function/object to do the file transformation) depends on context, but both approaches serve the DRY principle (Don’t Repeat Yourself). The result is cleaner, more maintainable code. When a bug in the archive handling is fixed, it benefits all uses of ZipProcessor. When a new operation is needed, you write only the new parts. This illustrates a broader point: prefer to refactor and generalize only after you have two or more concrete cases. It’s easier to design an abstraction when you’ve seen a couple of real examples. Premature abstraction can lead to needlessly complicated designs. OOP is a tool to manage complexity, but it’s not a silver bullet – sometimes a simple function or script is more straightforward until requirements grow.

Object-oriented programming in Python is less about rigid rules and more about practical design choices. Start with the data that matters. Build simple classes using tools like dataclasses to avoid boilerplate. Grow your design incrementally, using properties and dunder methods (like __str__) to polish the interface as you go. Always ask: do I truly need a class here, or will basic data structures do? Embrace Python’s flexibility – you can mix and match procedural and OO styles in one program, using whatever makes the code most understandable.

Finally, keep an eye on duplication and coupling. Well-designed classes can eliminate redundant code and make your software easier to extend. But over-engineering is a trap: every added class or pattern should earn its keep by simplifying the rest of the code. The beauty of Python’s take on OOP is that it doesn’t force you into one paradigm. As you read through Lott’s deep dive on OOP fundamentals and advanced patterns, you’ll see this theme again and again: great Python code finds the right balance between simplicity and abstraction.

Object orientation pays off when it sharpens your data model and reduces duplication. If that’s the spirit you want to carry into practice, the two pieces in our Expert Insight section that follows move from framing to executable patterns in Python, with clear heuristics for when not to use a class.

Decision rules for classes vs. tuples/lists + functions; Pythonic encapsulation via properties instead of boilerplate getters/setters; DRY by generalising a ZIP file processor; managers/façades to coordinate subsystems.

A data-first path out of the blank screen: @dataclass to prototype, @property for derived state, __str__ to make objects readable, and the moment to introduce Hand/Deck rather than pushing logic into lists.

Sponsored:

Apache Airflow® 3: Open source platform for developing, scheduling, and monitoring batch-oriented workflows in Python.

Upgrading to Apache Airflow® 3 will give you access to powerful new features like a modernized UI, event-based scheduling, and streamlined backfills.

Here is a FREE GUIDE with Airflow 3 Tips & Code Snippets to help you start developing DAGs in Airflow 3 today.

You’ll learn:

That’s all for today. Thank you for reading this issue ofDeep Engineering. We’re just getting started, and your feedback will help shape what comes next. Do take a moment tofill out this short surveywe run monthly—as a thank-you, we’ll addone Packt creditto your account, redeemable for any book of your choice.

We’ll be back next week with more expert-led content.

Stay awesome,
Divya Anne Selvaraj
Editor-in-Chief,Deep Engineering

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.