Before you start

This is the first lesson of the LLD course. Read this first — it takes 3 minutes and explains what the course is about.

Why start with classes and objects?

Every design problem — Parking Lot, Splitwise, Chess, Uber — starts the same way:

1. Read the problem.
2. Find the real-world things in it.
3. Give each thing a class.

You can't do the advanced lessons if step 3 feels hard. This lesson makes step 3 easy.

The mental model

A class is a blueprint. An object is one real thing built from that blueprint. Book is the blueprint. Your copy of Designing Data-Intensive Applications is an object.

Two objects built from the same class don't share data. They have the same fields and the same methods, but their values are different.

What a real design interview looks like

The interviewer describes a problem. You have 45 minutes. You need to:

1. Ask clarifying questions (3-5 minutes)
2. Find the classes you need (5-10 minutes) ← today's lesson
3. Sketch how the classes connect
4. Write the classes and methods
5. Walk through an example with the interviewer

Step 2 is the one nobody teaches. It looks easy, so most students skip it and start typing code. Then the interviewer asks "what if the user has two payment methods?" and they're stuck — because they never made Payment a separate class.

Every lesson in this course drills one piece of this flow. Today: turning "there's a book in the problem" into class Book.

About the tests

There's a hidden test_solution.py file that decides whether your code passes. You can't see it in this lesson — the objective above tells you everything the tests check.

Real jobs work the same way: someone tells you the requirements, and you write code to match. The requirements ARE the spec.

The grader runs the tests when you click Submit. Green = pass.

What comes next

The next four lessons cover more OOP basics: encapsulation, inheritance, composition, and polymorphism. Same format — read, write code, get feedback. By the end of the module you'll be ready for the design patterns.

Every design problem starts the same way. You read the problem, find the real-world things in it, and give each one a class. Before we design a Parking Lot or a Splitwise, you need to be comfortable writing a single class.

A class is a blueprint. An object is one thing built from that blueprint.

class Book:
    def __init__(self, title, author):
        self.title = title
        self.author = author

    def summary(self):
        return f"{self.title} by {self.author}"

Three things to notice:

1. class Book: — this creates a class named Book. Python style is to name classes with a capital letter (Book, not book).
2. __init__ — this is the setup function. Python runs it every time you create a new Book. self means "the Book being created right now".
3. self.title = title — this stores the title on the Book. Every Book you create has its own title and author.

You use the class like this:

b = Book("Designing Data-Intensive Applications", "Kleppmann")
print(b.summary())   # Designing Data-Intensive Applications by Kleppmann

Two Books don't share data. Changing one doesn't affect the other:

b1 = Book("DDIA", "Kleppmann")
b2 = Book("SICP", "Abelson")
b1.title = "DDIA (2nd ed)"
print(b2.title)   # SICP — b2 is unchanged

Your task

You're building the first piece of a Library app. In main.py, create a Book class that:

1. Takes title and author when you create it, and stores them on the object.
2. Has a method summary() that returns a string like "<title> by <author>". Example: Book("SICP", "Abelson").summary() should return "SICP by Abelson".
3. Has a method describe() that returns a longer string: "'<title>' — a book by <author>". Example: Book("SICP", "Abelson").describe() should return "'SICP' — a book by Abelson".

Three easy-to-miss things:

• Every method needs self as the first parameter: def summary(self):, not def summary():.
• The tests check what your method returns, not what it prints. Use return, not print.
• The em-dash in describe is — (a wider character), not a regular hyphen -. Copy it from the string above if your keyboard doesn't type it.

How to run your code

• Click Run — this executes python3 main.py and shows any output in the panel below. Use it to check for syntax errors or crashes.
• Click Submit — this runs the tests. When they pass, the lesson is complete.

You don't need to type any commands yourself.