Building software is a lot like building a house: you don't shape every brick from scratch, you assemble pieces that already exist. Composition in Python lets you do exactly that, combining existing objects inside other objects to model complex systems without leaning on inheritance. If you're learning object oriented programming and want cleaner, more flexible relationships between your classes, this is the technique you need.

What is composition in Python and why does it matter?

Composition is a design approach where one class contains instances of other classes as part of its own state. Instead of saying a class is a type of another (inheritance), you say it has one or many.

What is composition in object oriented programming? It's a relationship where an object holds other objects as attributes and uses their behavior. A Library that stores a list of Book objects is composition in action.

In the example we built, a Library class holds a list of books and a list of users. That single decision changes how you scale the system, because the library becomes the central piece that administers everything else.

How do you implement composition with a Library class?

We started from the previous challenge, which already had a LibroProtocol defining prestar, devolver and calcular_duracion, plus two implementations: LibroFisico with a 7 day loan and LibroDigital with a 14 day loan. With those building blocks ready, we created a new class to compose them.

Designing the constructor and its attributes

The Biblioteca class receives a name and initializes two empty lists by default. That setup is the entire foundation of composition here.

• nombre: a string identifying the library, for example Platzi Biblioteca.
• libros: a list that will hold Libro objects, empty by default.
• usuarios: a list that will hold user objects, also empty by default.

Once you instantiate the library, you assign the list of books directly to biblioteca.libros. In our test we added three: Mi libro, Mi libro no disponible (with disponible=False) and Otro libro. Two available, one not.

Adding methods that use the composed objects

Here's where composition pays off. You can write methods inside Biblioteca that operate on the contained objects without duplicating code in another class.

python def libros_disponibles(self): return [libro.titulo for libro in self.libros if libro.disponible]

Notice how the method reaches into each libro to read its disponible and titulo attributes. The Library doesn't need to know how a book is built internally, it just uses what the book exposes. When you run print(biblioteca.libros_disponibles()) you get only the titles that are actually available, and toggling disponible to True or False changes the output instantly.

When should you choose composition over inheritance?

This is the question that trips up most developers learning OOP. The rule is simpler than it looks once you frame it as a sentence about the relationship.

Composition vs inheritance: which one do I use? Use inheritance when the relationship is is a, like a professor is a user. Use composition when it's has a, like a library has many users.

A few signals that point you toward composition:

• You need one class to coordinate several others, like Biblioteca administering books and users.
• You want flexibility to swap or extend the contained objects without rewriting hierarchies.
• The relationship is about ownership or aggregation, not about specialization.

Inheritance locks you into a vertical chain. Composition gives you horizontal flexibility, which is exactly what a system that grows in features needs.

How does composition give you flexibility that inheritance can't?

In our library project, Biblioteca is becoming one of the most important classes because it manages multiple types of objects at once. It can hold LibroFisico and LibroDigital instances side by side, since both follow the same protocol, and it can also manage users. That kind of orchestration is hard to express with inheritance alone.

And here's the interesting part: the same libros_disponibles pattern can be reused for users, loans, reservations or any other entity you add later. You're not extending a class, you're composing capabilities.

Can a class use composition and inheritance at the same time? Yes. A Profesor can inherit from Usuario (is a) while a Biblioteca composes a list of Profesor objects (has many). They solve different problems.

Now it's your turn. What other composition relationship would make sense in this library system? Think about loans, reservations, categories or anything else that a library has. Drop your idea in the comments.