Chapter 12. Subtyping

Most of Part II has focused on creating your own types and defining interfaces. These types do not exist in isolation; types are often related to one another. So far, you’ve seen composition, where types use other types as members. In this chapter, you’ll learn about subtyping, or creating types based on other types.

When applied correctly, subtyping makes it incredibly easy to extend your codebase. You can introduce new behaviors without ever worrying about breaking the rest of your codebase. However, you must be dilligent when creating a subtyping relationship; if you do it poorly, you can decrease the robustness of your codebase in unexpected ways.

I’ll start with one of the most common subtype relationships: inheritance. Inheritance is seen as a traditional pillar of object-oriented programming (OOP).1 Inheritance can be tricky if not applied correctly. I’ll then move on to other forms of subtyping present in the Python programming language. You’ll also learn about one of the more fundamental SOLID design principles, the Liskov Substitution Principle. This chapter will help you make sense of when and where subtyping is appropriate and where it is not.

Inheritance

Most developers immediately think of inheritance when they talk about subtyping. Inheritance is a way of creating a new type from another type, copying all the behaviors into the new type. This new type is known as a child class, derived class, or subclass. In contrast, the type being ...

Get Robust Python now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.