Добро пожаловать на новый уровень мастерства в Python! На этапе Intermediate мы перестаем писать линейные скрипты и переходим к созданию структурированных, масштабируемых систем. В предыдущих уроках вы познакомились с концепцией объектно-ориентированного программирования (ООП) и изучили магический метод __init__, который служит для инициализации начального состояния объекта. Однако класс, состоящий только из атрибутов данных — это по сути просто контейнер, похожий на продвинутый словарь. Настоящая сила ООП раскрывается тогда, когда мы наделяем наши объекты поведением. И именно за поведение отвечают методы экземпляра.

Метод экземпляра — это функция, которая определена внутри тела класса и предназначена для работы с конкретными объектами (экземплярами) этого класса. Представьте себе чертеж автомобиля. Чертеж описывает характеристики (состояние): цвет, мощность двигателя, текущий уровень топлива. Но автомобиль должен уметь заводиться, разгоняться и тормозить. Эти действия — это методы. Когда вы вызываете метод 'разгоняться', изменяется состояние конкретного автомобиля (его скорость увеличивается, а уровень топлива падает). Важно понимать фундаментальное отличие метода от обычной функции: функция существует сама по себе в глобальной области видимости модуля, тогда как метод жестко привязан к объекту и имеет автоматический доступ ко всем его внутренним данным.

В Python мы следуем принципам 'The Zen of Python', один из которых гласит: Явное лучше, чем неявное. Именно поэтому методы в Python работают не так, как в некоторых других языках (например, Java или C++), где доступ к атрибутам текущего объекта происходит неявно. В Python каждый метод экземпляра должен принимать как минимум один обязательный параметр, который по договоренности (конвенции) называется self. Этот параметр — не ключевое слово языка, а просто переменная, но она играет критически важную роль. self содержит ссылку на тот самый объект в оперативной памяти, для которого в данный момент был вызван метод. Без этого параметра метод не смог бы понять, данные какого именно объекта ему нужно изменить.

В рамках этого урока мы будем использовать подход Scaffolding (Строительные леса). Мы не будем сразу строить сложную систему. Сначала мы заложим фундамент (разберем механику self на атомарном уровне), затем возведем каркас (научимся менять состояние и вызывать методы внутри методов), и, наконец, вдохнем жизнь в проект (Project-Based Learning) — создадим полноценную систему управления библиотекой. Помните: обучение — это активный процесс. Мы будем использовать методики Active Recall и Microlearning, чтобы проверять ваши знания после каждого нового концепта. Приготовьтесь к серьезному погружению в механику Python!

Давайте детально разберем код из предыдущего примера, используя метод глубокого анализа. Мы создали класс BankAccount, который имитирует работу банковского счета. Внутри этого класса определены два метода: магический конструктор __init__ и наш собственный метод экземпляра deposit. Обратите внимание на определение метода: def deposit(self, amount):. Здесь мы видим два параметра. Однако при вызове метода account.deposit(500) мы передаем только один аргумент — число 500. Куда же исчез параметр self и почему интерпретатор не выдал ошибку TypeError: deposit() missing 1 required positional argument?

Ответ кроется в том, как Python обрабатывает вызовы методов 'под капотом' (under the hood). Синтаксис account.deposit(500) — это на самом деле просто элегантный синтаксический сахар (syntactic sugar). Когда интерпретатор видит этот вызов, он автоматически преобразует его в следующий вид: BankAccount.deposit(account, 500). То есть Python берет класс, находит в нем соответствующую функцию, а затем первым аргументом неявно передает сам объект (экземпляр account), перед которым стояла точка. Именно этот объект попадает в параметр self. Таким образом, внутри метода переменная self становится синонимом переменной account. Они указывают на один и тот же участок в оперативной памяти.

Понимание этой механики является водоразделом между начинающим (Junior) разработчиком и специалистом уровня Intermediate. Если вы не понимаете, что такое self, ваши программы будут страдать от неожиданных багов, связанных с потерей контекста. Например, если вы попытаетесь обратиться к атрибуту баланса просто как balance += amount внутри метода, Python выдаст ошибку UnboundLocalError, так как он решит, что вы пытаетесь создать локальную переменную balance внутри метода, которая никак не связана с атрибутом объекта. Использование self.balance явно говорит интерпретатору: 'Найди объект, который вызвал этот метод, зайди в его пространство имен (namespace) и измени атрибут именно там'. Это защищает состояние объекта от несанкционированного доступа и глобальных коллизий имен.

Давайте еще раз вспомним философию ООП: Инкапсуляция. Объекты инкапсулируют (скрывают внутри себя) свои данные и предоставляют методы для работы с этими данными. Метод deposit — это интерфейс, через который внешний мир общается со счетом Алисы. Вместо того чтобы программист вручную менял баланс (что может привести к ошибкам, например, занесению отрицательного значения), метод берет эту ответственность на себя. В будущих блоках мы научимся добавлять проверки внутри методов, чтобы сделать наши объекты по-настоящему надежными.

Мы переходим ко второму циклу нашего обучения, где глубоко исследуем управление состоянием объекта (State Manipulation). В терминологии программирования состояние (state) — это набор текущих значений всех атрибутов объекта в любой заданный момент времени. Когда мы создаем объект car = Car(speed=0), его начальное состояние — нулевая скорость. Методы экземпляра — это основной и самый безопасный инструмент для изменения (мутации) этого состояния. Вспомните, как в модуле базовых типов мы говорили про Mutable vs Immutable (изменяемые и неизменяемые типы). Экземпляры пользовательских классов в Python по умолчанию являются изменяемыми (Mutable). Это означает, что мы можем менять их содержимое без создания нового объекта в памяти.

При проектировании методов важно следовать правилу единственной ответственности (Single Responsibility Principle из SOLID, хоть мы и на уровне Intermediate, полезно знать основы архитектуры). Метод должен делать только одну вещь, но делать ее хорошо. Например, метод accelerate(self, value) должен только увеличивать скорость, а метод brake(self) — только уменьшать. Если метод пытается сделать слишком много (например, и изменить скорость, и отправить email, и записать данные в файл), он становится сложным для тестирования и поддержки (так называемый 'God object' или 'Spaghetti code'). В Python методы позволяют нам организовывать логику так, чтобы изменение состояния происходило предсказуемо.

Рассмотрим механику изменения атрибутов через метод. Когда метод выполняет операцию self.speed += 10, интерпретатор выполняет следующие шаги: 1. Обращается к объекту по ссылке self. 2. Ищет в его словаре атрибутов (__dict__) ключ 'speed'. 3. Извлекает текущее значение (например, 0). 4. Прибавляет к нему 10. 5. Записывает новое значение (10) обратно по ключу 'speed'. Весь этот процесс происходит мгновенно и локально для конкретного объекта. Если у нас есть два разных автомобиля (car1 и car2), вызов car1.accelerate() никак не повлияет на car2, потому что при вызове метода параметр self у каждого объекта указывает на свой уникальный адрес в памяти.

Также стоит отметить, что методы могут не только изменять существующие атрибуты, но и динамически создавать новые 'на лету'. Однако, согласно стандарту PEP 8 и хорошему тону программирования, все атрибуты экземпляра должны быть инициализированы в методе __init__. Если метод создает новый атрибут, которого не было в конструкторе, это может запутать других разработчиков, так как структура объекта становится непредсказуемой до вызова этого конкретного метода. Всегда старайтесь определять 'каркас' объекта сразу при создании.

В предыдущем коде с классом Player мы продемонстрировали, как метод take_damage взаимодействует с атрибутом self.health. Это классический пример инкапсуляции бизнес-логики. Представьте, если бы мы меняли здоровье персонажа напрямую снаружи: hero.health -= 150. В этом случае здоровье стало бы отрицательным (например, -50), что бессмысленно для логики игры. Внедрив изменение состояния внутрь метода take_damage, мы добавили защитную проверку if self.health <= 0:, которая гарантирует, что здоровье никогда не опустится ниже нуля. Это одна из главных причин, почему в объектно-ориентированном программировании предпочитают скрывать данные и работать с ними исключительно через методы (интерфейсы).

Теперь давайте обсудим концепцию внутренних вызовов методов (когда один метод вызывает другой метод того же класса). Очень часто сложные операции требуют разделения на несколько более мелких, атомарных шагов. В Python, чтобы вызвать метод внутри другого метода того же объекта, мы должны снова использовать ключевое слово self. Синтаксис выглядит так: self.other_method(). Если вы забудете написать self. и напишете просто other_method(), интерпретатор Python будет искать эту функцию в глобальной области видимости модуля, не найдет ее и выдаст ошибку NameError: name 'other_method' is not defined.

Такое поведение может поначалу сбивать с толку разработчиков, пришедших из языков вроде Java или C#, где внутренние методы можно вызывать просто по имени. Но вспомните 'Zen of Python': Явное лучше, чем неявное. Наличие префикса self. делает код предельно прозрачным при чтении. Когда вы просматриваете длинный и сложный метод, вы всегда можете с первого взгляда отличить вызов внутренней функции класса (self.calculate_tax()) от вызова внешней библиотечной функции (например, math.sqrt() или встроенной print()). Эта явность значительно упрощает процесс отладки и код-ревью.

Взаимодействие методов между собой позволяет строить элегантные цепочки логики. Например, метод level_up() может не только увеличивать уровень персонажа, но и автоматически вызывать методы self.restore_health() и self.increase_stats(). Таким образом, сложная бизнес-транзакция инкапсулируется в одном месте, а код остается модульным (Microlearning в действии — разбиваем сложное на простые компоненты). В следующем практическом блоке мы посмотрим, как выглядит этот синтаксис в реальном коде, и закрепим его с помощью Active Recall.

Мы продолжаем наше погружение и переходим к третьему циклу — передаче аргументов в методы экземпляра. Вы уже знаете, что методы — это функции, привязанные к объекту. А значит, к ним применимы абсолютно все правила работы с аргументами, которые вы изучали в модуле функционального программирования. Вы можете использовать позиционные аргументы, именованные аргументы (keyword arguments), значения по умолчанию, а также произвольное количество аргументов через *args и **kwargs. Единственное отличие состоит в том, что параметр self всегда должен стоять на первом месте в определении метода. Все остальные параметры следуют за ним.

Давайте вспомним задачу из нашего сборника практических упражнений: создание гибкой функции-логгера. Мы можем адаптировать этот функционал и внедрить его внутрь класса, создав мощную систему логирования для любого объекта. Использование распаковки аргументов *args (кортеж позиционных аргументов) и **kwargs (словарь именованных аргументов) делает методы невероятно гибкими. Например, вы можете написать метод для отправки уведомлений, который принимает текст сообщения, а затем любое количество дополнительных настроек через **kwargs (приоритет, формат, email получателя и т.д.). Внутри метода вы просто перебираете словарь kwargs.items() и применяете нужные настройки.

Правила области видимости переменных (LEGB - Local, Enclosing, Global, Built-in) работают внутри методов точно так же, как и внутри обычных функций. Когда метод получает аргументы, они становятся локальными переменными для этого метода. Если вы назовете параметр метода так же, как и атрибут объекта (например, метод принимает аргумент price, и у объекта есть атрибут self.price), путаницы не возникнет. Просто переменная price будет ссылаться на локальный аргумент функции, а self.price — на атрибут объекта. Это еще одно доказательство гениальности решения Гвидо ван Россума сделать self явным: вы никогда не перекроете (shadow) атрибуты объекта локальными переменными по неосторожности.

При проектировании API ваших классов (Application Programming Interface — того, как другие программисты будут использовать ваш код) старайтесь делать методы максимально удобными. Используйте type hints (аннотации типов) для аргументов методов, чтобы современные IDE могли подсказывать, какие данные ожидает метод. Например: def add_product(self, product_name: str, price: float = 0.0) -> None:. Обратите внимание на значение по умолчанию price: float = 0.0. В следующем цикле мы подробно разберем опасную ловушку, связанную со значениями по умолчанию в методах, которая часто приводит к багам в коде начинающих разработчиков.

Отлично, мы разобрались с аргументами. Теперь давайте обратимся к реальным диалогам и ситуациям из рабочего процесса (Code Review Simulation). В нашем архиве есть классический пример ошибки уровня Junior. Ситуация следующая: разработчик пишет класс для управления группой студентов. Он создает метод add_student, который должен добавлять студента в список. Если список не передан при вызове, метод должен использовать пустой список по умолчанию. Разработчик пишет такой код: def add_student(self, name, students=[]): students.append(name). И вдруг обнаруживает, что студенты из одной группы странным образом 'перетекают' в другую группу! Senior-разработчик на код-ревью сразу диагностирует проблему: Mutable Default Argument (Изменяемый аргумент по умолчанию).

Почему это происходит? В Python значения по умолчанию для аргументов функций и методов вычисляются только один раз — в момент компиляции модуля (когда интерпретатор впервые читает определение класса), а не при каждом вызове метода. Когда интерпретатор видит students=[], он создает в памяти один-единственный список. Если вы вызываете метод и не передаете свой список, Python использует этот 'глобальный' для метода список. При добавлении студента в этот список (через append), список изменяется. При следующем вызове метода (даже для совершенно другого объекта этого класса), Python снова использует тот же самый измененный список из памяти! Это приводит к утечке состояния между независимыми объектами.

Как исправить эту проблему? Правило (Best Practice) звучит так: никогда не используйте изменяемые объекты (списки [], словари {}, множества set()) в качестве значений по умолчанию для аргументов. Вместо этого используйте неизменяемый тип None. Внутри тела метода вы должны проверить: если аргумент равен None, тогда создайте новый пустой список. Паттерн выглядит так: def add_student(self, name, students=None): if students is None: students = []. В этом случае при каждом вызове метода без аргумента будет создаваться абсолютно новый, чистый список в оперативной памяти, и изоляция объектов будет сохранена.

Эта ситуация подчеркивает важность глубокого понимания того, как Python работает под капотом (интерпретируемость и управление памятью). Знание синтаксиса — это только первый шаг. Понимание побочных эффектов (side effects) и жизненного цикла объектов — вот что делает вас настоящим инженером. Закрепите этот паттерн с помощью None в памяти, так как он встречается в реальном продакшен-коде повсеместно, и понимание этой концепции обязательно проверяется на собеседованиях уровня Middle.

Мы переходим к пятому циклу: интеграции функционального программирования внутрь методов экземпляра. В архиве упражнений вы решали задачу на продвинутую фильтрацию и сортировку данных с использованием анонимных функций (lambda) и генераторов списков (list comprehensions). Одно из преимуществ Python заключается в том, что он является мультипарадигменным языком. Вы можете легко смешивать объектно-ориентированный и функциональный стили, получая максимум от обоих подходов. Методы экземпляра — идеальное место для инкапсуляции сложной логики обработки данных.

Представьте, что у вас есть класс Inventory, который хранит внутри себя список товаров (словарей или других объектов). Вам нужно написать метод, который возвращает отсортированный список товаров по цене. Вместо того чтобы писать громоздкие циклы for и вручную менять элементы местами, вы можете использовать встроенную функцию sorted() или метод списка .sort() внутри вашего метода экземпляра. А чтобы указать, по какому именно критерию сортировать, вы передаете lambda-функцию в параметр key. Код будет выглядеть примерно так: self.items.sort(key=lambda x: x['price']). Это классический 'Pythonic way' — писать кратко, выразительно и эффективно.

Использование генераторов списков (List Comprehensions) внутри методов также значительно улучшает читаемость кода. Например, если вам нужен метод get_expensive_items(self, threshold), который возвращает только те товары, цена которых выше заданного порога, вы можете реализовать его в одну строку: return [item for item in self.items if item['price'] > threshold]. Этот подход не только экономит место, но и работает быстрее на уровне интерпретатора CPython, так как генераторы оптимизированы на языке Си.

Важно понимать, что когда вы используете lambda или list comprehension внутри метода, они имеют доступ к локальной области видимости этого метода, включая переменную self. Это позволяет вам создавать сложные фильтры, которые зависят от текущего состояния самого объекта. Например: [item for item in self.items if item['category'] == self.current_category_filter]. Таким образом, функциональные конструкции становятся мощным инструментом в арсенале ООП-разработчика, позволяя манипулировать внутренним состоянием объектов лаконично и красиво.

Настало время применить все изученные концепции на практике. Мы переходим к Project-Based Learning (Проектное обучение). В соответствии с нашими архивами, мы разработаем 'Систему управления библиотекой'. Начнем с базовой сущности — класса Book. Наша цель — спроектировать объект, который не только хранит данные о книге (название и автор), но и управляет своим внутренним состоянием: выдана книга читателю или находится в библиотеке. Это идеальный пример для демонстрации работы методов экземпляра.

При проектировании класса мы должны определить его состояние. В методе __init__ мы зададим атрибуты title и author. Но нам также нужен флаг, который будет показывать статус книги. Мы назовем его _is_borrowed и по умолчанию установим в False (так как новая книга изначально доступна). Обратите внимание на префикс из одного подчеркивания (_) в имени переменной. В Python нет строгих модификаторов доступа (как private или protected в Java). Подчеркивание — это соглашение (конвенция) между программистами, которое буквально кричит: 'Внимание! Это внутренний атрибут объекта. Пожалуйста, не обращайтесь к нему напрямую извне (например, book._is_borrowed = True)'. Все манипуляции с этим атрибутом должны происходить только через публичные методы класса.

Это и есть реализация принципа инкапсуляции. Почему это так важно? Представьте, что в будущем логика библиотеки усложнится: при выдаче книги нужно будет не только менять флаг _is_borrowed, но и фиксировать дату выдачи, проверять наличие штрафов у читателя и отправлять лог на сервер. Если другие программисты привыкнут менять атрибут напрямую (в обход методов), они сломают эту сложную логику, так как смена флага произойдет, а остальные действия (запись лога, даты) — нет. Создавая публичные методы borrow_book() и return_book(), мы создаем 'бутылочное горлышко', через которое проходят все изменения состояния. Это гарантирует контроль и безопасность данных.

В следующих блоках мы реализуем эти методы шаг за шагом. Мы добавим в них условные операторы if, чтобы проверять текущее состояние объекта перед тем, как его изменить. Это называется 'защитное программирование' (Defensive Programming). Метод не должен слепо выполнять действие; он должен сначала убедиться, что действие имеет смысл в текущем контексте (нельзя выдать книгу, которая уже выдана).

Продолжаем работу над проектом библиотеки. Теперь мы напишем метод borrow_book(self) (взять книгу). Его задача — изменить состояние атрибута self._is_borrowed с False на True. Однако, как мы обсуждали ранее, метод должен быть 'умным'. Он должен реализовывать бизнес-логику. Если книга уже выдана, метод должен сообщить об этом и предотвратить повторную выдачу. Для этого мы используем простую проверку: if self._is_borrowed:.

Давайте проанализируем поток выполнения (Control Flow) внутри этого метода. Когда кто-то вызывает book1.borrow_book(), интерпретатор заходит в метод и первым делом оценивает логическое выражение if self._is_borrowed. Так как атрибут хранит булево значение, он идеально подходит для условий. Если книга уже на руках (значение True), мы выводим предупреждение (например, с помощью print или, в реальных системах, вызываем исключение/возвращаем статус ошибки) и немедленно завершаем работу метода, используя команду return False. Ранний возврат (Early Return) — это отличная практика написания чистого кода, которая позволяет избежать глубокой вложенности if/else.

Если же проверка пройдена успешно (книга доступна), метод продолжает работу. Он изменяет состояние: self._is_borrowed = True. Это ключевой момент мутации объекта. В оперативной памяти значение по этому адресу перезаписывается. Затем метод выводит подтверждающее сообщение и возвращает True (сигнализируя внешней системе, что операция прошла успешно). Таким образом, метод экземпляра выступает в роли конечного автомата (State Machine), который переводит объект из одного разрешенного состояния в другое, не допуская некорректных переходов.

Именно в таких методах проявляется вся мощь ООП. Код снаружи класса (в основной программе) становится предельно простым и читабельным. Вы просто вызываете метод, а всю сложную работу по проверке статусов, обработке флагов и выводу сообщений берет на себя сам объект. Это снижает когнитивную нагрузку на программиста, использующего ваш класс, и делает систему легко расширяемой в будущем.

Мы продолжаем строить нашу систему. Логичным шагом после создания метода выдачи книги будет реализация метода возврата — return_book(self). Этот метод будет выполнять обратную операцию: переводить флаг self._is_borrowed обратно в значение False. На первый взгляд, это элементарная операция в одну строку. Но давайте задумаемся как архитекторы: а что если читатель попытается вернуть книгу, которую он на самом деле не брал (или она уже числится в библиотеке)? По-хорошему, здесь тоже нужна защитная логика.

Внутри метода return_book мы можем написать проверку: if not self._is_borrowed: print('Книга и так находится в библиотеке!'). Если книга действительно была выдана, мы меняем флаг: self._is_borrowed = False. Таким образом, мы замыкаем жизненный цикл объекта. Книга может бесконечно переходить из состояния 'доступна' в 'выдана' и обратно, и все эти переходы строго контролируются нашими методами. Внешний код никогда не сможет случайно перевести книгу в неопределенное состояние.

Теперь давайте поговорим об извлечении данных. В нашем классе есть внутренний атрибут _is_borrowed (булево значение). Внешнему коду (например, пользовательскому интерфейсу) часто нужно просто узнать текущий статус книги в понятном виде (строкой 'Доступна' или 'Выдана'), не меняя его. Для этого мы можем написать метод status(self). Этот метод не будет изменять атрибуты объекта (он не является мутатором). Он просто прочитает внутреннее состояние и вернет отформатированную строку. В программировании такие методы часто называют геттерами (getters).

Реализация метода status — отличное место для использования тернарного оператора Python. Вместо написания длинного if/else, мы можем вернуть значение в одну строку: return 'Выдана' if self._is_borrowed else 'Доступна'. Этот метод демонстрирует еще один важный принцип: методы могут предоставлять производные данные (derived data). Внешнему коду не нужно знать, как именно класс хранит статус внутри (в виде True/False, числа 0/1 или как-то еще). Внешний код просто вызывает метод status() и получает готовую к отображению человекочитаемую строку. Это мощнейший уровень абстракции.

Мы подходим к одной из самых элегантных техник ООП в Python — Method Chaining (Цепочки вызовов методов). Вы наверняка сталкивались с этим в других языках или библиотеках, например, в библиотеке pandas или при работе со строками в самом Python: text.strip().lower().replace('a', 'b'). Метод цепочек позволяет вызывать несколько методов одного объекта последовательно в одной строке кода. Это делает код невероятно компактным и читабельным, формируя так называемый 'Fluent Interface' (Текучий интерфейс).

В чем секрет этой магии? Как заставить наши собственные классы поддерживать такой синтаксис? Секрет поразительно прост: каждый метод экземпляра, который участвует в цепочке, должен заканчиваться инструкцией return self. Давайте разберем механику по шагам. Когда интерпретатор видит выражение obj.method1().method2(), он сначала выполняет obj.method1(). Если method1 изменяет состояние объекта, а затем возвращает self (то есть ссылку на этот же самый объект), то результатом первого вызова становится сам объект. Следовательно, .method2() применяется к результату первого вызова — то есть к тому же самому объекту! Эта цепочка может продолжаться бесконечно долго.

Давайте представим класс QueryBuilder, который строит SQL-запросы к базе данных. Вместо того чтобы писать запросы вручную, мы можем создать методы select, where и limit. Если каждый из них возвращает self, мы сможем написать код так: query.select('*').where('age > 18').limit(10). Это читается как обычный английский текст. Method Chaining часто используется в паттерне проектирования 'Builder' (Строитель) и при конфигурировании сложных объектов.

Однако, с этой техникой стоит быть осторожным. Если метод выполняет действие, которое концептуально должно возвращать новые данные (например, метод расчета суммы или поиска в базе), он не должен возвращать self. Возвращать self логично только для методов-мутаторов (тех, что меняют состояние текущего объекта) или методов конфигурации. В нашей библиотечной системе метод borrow_book мог бы возвращать self, если бы мы хотели позволить читателю взять книгу и сразу же запросить ее статус: book.borrow_book().get_status(). Это вопрос дизайна вашего API (Application Programming Interface), и на уровне Intermediate вы уже должны осознанно принимать такие архитектурные решения.

Мы приближаемся к финалу нашего урока. Прежде чем подвести итоги, давайте коснемся важной темы, которая связывает то, что мы выучили сегодня, с будущими уроками: Магические методы (Dunder Methods). Вы уже знаете метод __init__. В Python существует множество других методов с двойным подчеркиванием спереди и сзади (отсюда название Dunder — Double UNDERscore). Самое важное, что вы должны сейчас усвоить: магические методы — это абсолютно такие же методы экземпляра, как и те, что мы писали сегодня. Они подчиняются тем же правилам, принимают self первым аргументом и имеют доступ к состоянию объекта.

Их 'магия' заключается только в том, что интерпретатор Python вызывает их автоматически при определенных системных событиях. Например, когда вы используете встроенную функцию print(obj), Python за кулисами ищет в вашем классе метод экземпляра с именем __str__(self) и вызывает его. Если вы напишете в вашем классе def __str__(self): return f'Книга: {self.title}', то при печати объекта вы увидите красивую строку, а не непонятную абракадабру с адресом памяти вроде <__main__.Book object at 0x7f...>.

Аналогично, когда вы пишете len(obj), Python вызывает метод __len__(self). Когда складываете объекты obj1 + obj2, вызывается метод __add__(self, other). Вся архитектура коллекций и операций в Python построена на этих методах. Вы можете переопределить их в своих классах, чтобы ваши объекты вели себя как встроенные типы данных Python. Это называется перегрузкой операторов (Operator Overloading), и мы будем подробно изучать это в будущих модулях. Но сейчас, написав десятки обычных методов экземпляра с параметром self, вы заложили прочнейший фундамент. Когда мы дойдем до магических методов, для вас они будут просто еще одной функцией, работающей с self.

Давайте резюмируем. Методы экземпляра — это сердце объектно-ориентированного программирования. Они инкапсулируют логику работы с данными, защищают состояние от некорректных изменений, позволяют объектам общаться друг с другом и делают ваш код модульным, тестируемым и поддерживаемым. Помните о важности параметра self, избегайте ловушек с изменяемыми аргументами по умолчанию и используйте функциональные приемы (lambda, list comprehensions) внутри методов для создания элегантного 'Pythonic' кода. Вы прошли большой путь от простого скриптинга до проектирования классов. Поздравляю с успешным прохождением этого важного этапа!