Class Relationships in Python

Python class relationships describe the different ways that classes can be connected to each other in an object-oriented system, and understanding this taxonomy of relationships is essential for designing code that is both correct and maintainable. Every time you write a class that references another class, whether by inheriting from it, storing an instance of it as an attribute, or accepting it as a method parameter, you are establishing a relationship between those two classes. The type of relationship you choose determines how tightly the classes are coupled, how easy they are to test in isolation, and how much your system resists or encourages change. Choosing the wrong relationship type is one of the most common sources of rigidity in object-oriented codebases, where a small change in one class forces cascading changes through dozens of others because the relationships between them are tighter than they need to be.

The articles on composition versus inheritance and single inheritance covered the two most prominent relationship types in detail. This article broadens the view to include the full spectrum: inheritance, composition, aggregation, association, and dependency. Each relationship type exists on a continuum from tightest to loosest coupling, and the general principle is to use the loosest relationship that satisfies your design requirements. Loose coupling means classes can be understood, tested, and changed independently, which makes your codebase more resilient to evolving requirements.

The terminology in this article comes from the Unified Modeling Language, or UML, a standard notation for describing software designs that has been used for decades across many programming languages. You do not need to learn UML diagrams to use these concepts effectively in Python, but understanding the relationship types that UML names helps you think clearly about how your classes should connect.

Inheritance: the tightest relationship

Inheritance is the strongest and most binding relationship between classes. When a child class inherits from a parent, it receives the parent's entire public interface and implementation. Every method the parent defines is available on the child. Every attribute the parent's constructor sets is present on child instances. The child cannot opt out of inheriting something it does not want, and any change to the parent's interface automatically affects every child class in the hierarchy. This tight coupling is the reason inheritance should be reserved for genuine is-a relationships where the child truly shares the parent's fundamental nature.

Inheritance is appropriate when you need the child to be usable everywhere the parent is expected, a property called substitutability. If every function that accepts a parent object should also accept a child object, and the child honors the parent's contract for every inherited method, inheritance is the right choice. If the child needs to hide or disable some of the parent's methods, the is-a relationship is probably not genuine, and composition is a better fit.

Composition: strong ownership

Composition creates a relationship where one object is composed of other objects and is responsible for their entire lifecycle. A House object that creates Room objects in its constructor and stores them as attributes is using composition. When the House is destroyed, the Rooms are destroyed with it because no other object holds references to them. The house owns its rooms completely.

In Python, composition is implemented by creating instances of the contained class inside the containing class, typically in the constructor. The contained objects are stored in attributes and are not exposed to external code unless the containing class deliberately provides access. This encapsulation gives the containing class full control over how the contained objects are used and prevents external code from interfering with the internal structure. Composition is the strongest has-a relationship and is appropriate when the contained object has no meaningful existence independent of the container.

Aggregation: shared references

Aggregation is a weaker form of has-a where the container holds a reference to an object that exists independently and may be shared with other containers. A Department object that receives a list of Employee objects in its constructor and stores them as an attribute is using aggregation. The Employees exist before the Department is created and continue to exist after the Department is destroyed. They may belong to multiple Departments simultaneously. The department aggregates employees but does not own them.

In Python, aggregation is implemented by accepting an existing object as a constructor or method parameter and storing a reference to it. The container does not create the object and does not control its lifecycle. Aggregation is appropriate when the contained object has an independent existence and the relationship between the container and the contained object is organizational rather than existential.

Association and dependency: the loosest connections

Association is a general term for any relationship where objects know about each other and can interact, but neither owns the other. A Teacher object that holds a reference to a Classroom object, where both can exist independently and the Teacher is not composed of Classrooms, is an example of association. The relationship is peer-to-peer: both objects are independent, and either can be replaced without affecting the fundamental nature of the other.

Dependency is the weakest and most transient relationship. A dependency exists when one class uses another class temporarily, typically as a method parameter, without storing a reference to it as an attribute. A function that accepts a Formatter object, calls its format method, and returns the result without saving the Formatter has a dependency on the Formatter class. The dependency lasts only for the duration of the method call. Dependencies are the ideal relationship when one object needs another only for a specific operation and does not need ongoing access.

Choosing the right relationship

The guiding principle for choosing between relationship types is to use the weakest coupling that satisfies your requirements. Weak coupling means classes know as little about each other as possible, which makes them easier to change independently. If a class only needs another class for a single method call, a dependency, where the other class is passed as a parameter and not stored, is sufficient. If the class needs ongoing access but does not own the other object, aggregation is appropriate. If the class creates and controls the lifecycle of the other object, composition is necessary.

Reserve inheritance for situations where the child genuinely is a specialized version of the parent and needs to be substitutable for the parent everywhere. If you are using inheritance only to share a few utility methods, those methods should probably be standalone functions or a separate utility class used through composition. The guidance to prefer composition over inheritance, discussed in detail in the composition versus inheritance article, is fundamentally about preferring weaker relationships over stronger ones when both could work.

The following table summarizes how each relationship type maps to Python code, though the mapping is about intent and design rather than syntax:

• Inheritance: class Child(Parent)
• Composition: self.part = Component() inside the constructor
• Aggregation: self.member = existing_object passed as a parameter
• Dependency: def method(self, helper) where helper is used and discarded