JavaRush /Курсы /Модуль 1: Python Core /Все является объектами

Все является объектами

Модуль 1: Python Core
9 уровень , 0 лекция
Открыта

1.1 Объекты и классы

Сегодня вы узнаете о том, как устроена типичная программа на Python. И главная новость: каждая программа на Python состоит из классов и объектов. Python – это объектно-ориентированный язык, и всё в нём является объектами: числа, строки, функции и даже классы являются объектами.

Так что же такое классы?

Начну с аналогии. Представьте, что вы хотите сделать небольшой корабль. Сначала нужно сделать чертёж, затем отдать его на завод, где по этому чертежу соберут корабль. Или десяток. Да вообще, сколько угодно кораблей. По одному чертежу строятся десятки идентичных кораблей, вот что важно.

В программировании на Python всё точно так же.

Чертежи

Программист — он как проектировщик. Только проектировщик рисует чертежи, а Python-программист пишет классы. Затем на основе чертежей создаются детали, а на основе классов — объекты.

Сначала мы пишем классы (делаем чертежи), а потом, во время исполнения программы, на основе этих классов Python создаёт объекты. Точно так же, как корабли создаются на основе чертежей.

Чертёж один, но кораблей может быть много. Корабли разные, у них разные имена, они возят разные грузы. Но они очень похожи: они все — корабли с идентичной конструкцией и могут выполнять аналогичные задачи.

Или вот ещё аналогия...

Муравейник

Муравейник — это хороший пример взаимодействия объектов. В простейшем муравейнике есть три класса муравьёв: королева, воины и рабочие муравьи.

Количество муравьёв каждого класса — разное. Королева — одна на весь муравейник, воинов — десятки, а рабочих муравьёв — сотни. Три класса и сотни объектов. Муравьи взаимодействуют друг с другом, с такими же муравьями и муравьями других классов по жёстко заданным правилам.

Это просто идеальный пример. В типичной программе всё точно так же. Есть главный объект, который создаёт объекты всех остальных классов. Объекты начинают взаимодействовать друг с другом и «внешним миром» программы. Внутри этих объектов жёстко запрограммировано их поведение.

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

Сначала вы должны написать классы для всех существующих в программе объектов, а потом ещё и описать их взаимодействие. Звучит сложновато, но это легче, чем кажется.

В Python все сущности во время работы программы являются объектами, а написание программы сводится к описанию различных способов взаимодействия объектов. Объекты просто вызывают методы друг друга и передают в них нужные данные.

Документация

А как узнать, какие данные передавать в методы? Тут всё уже придумано до вас.

Обычно у каждого класса есть описание, в котором говорится, для чего он создан. Также обычно и у каждого публичного метода есть описание: что он делает и какие данные нужно в него передавать.

Чтобы использовать класс, нужно в общих чертах знать, что он делает. А также нужно точно знать, что делает каждый его метод. И совсем не обязательно знать, как он это делает. Такая себе волшебная палочка.

Давайте посмотрим на код — копирование файла:


src = open('source.txt', 'r')
dst = open('destination.txt', 'w')
            
for line in src:
    dst.write(line)
            
src.close()
dst.close()
        

Если прочитать этот код построчно, можно догадаться, что он делает в общих чертах. Хотя тут нужен опыт и практика. Так что спустя некоторое время этот код вам покажется знакомым и понятным.

1.2 Проектирование программы

Проектирование программы — это целое искусство. Это и просто, и сложно одновременно. Просто, потому что никаких жёстких законов нет: всё, что не запрещено — разрешено. Ну а сложно тоже по этой причине: очень много способов что-то сделать, и непросто найти лучший.

Проектировать программу — это как писать книгу. С одной стороны, вы просто пишете буквы, слова, предложения. А с другой — важен сюжет, характеры героев, внутренние противоречия, конфликты, стиль повествования, интрига и т.п.

Главное — понимать, для кого вы пишете код. Помните, что ваш код предназначен для других программистов.

Разработка любого продукта — это внесение изменений: добавили здесь, удалили там, переделали тут. И так, маленькими итерациями, рождаются большие, огромные и гигантские проекты.

Главное требование к коду — он должен быть понятен другим программистам. Неправильный, но понятный код можно исправить. Правильный и непонятный код улучшать не получится. Его останется только выбросить.

Так как же писать хороший и понятный код?

Для этого нужно делать три вещи:

  • Писать хороший и понятный код внутри методов — самое простое.
  • Решить, какие сущности должны быть в программе.
  • Правильно разбивать программу на логические части.

Что же стоит за этими понятиями?

Писать хороший код внутри методов

Если у вас хотя бы начальный уровень английского, возможно, вы обратили внимание, как легко иногда читается код: как предложения на английском языке:

  • class Cat(Pet) – класс Кот расширяет класс ДомашнееЖивотное.
  • while stream: – пока поток не пуст ...
  • a if a < b else b – если а меньше b, вернуть а, иначе вернуть b.

Так сделано специально. Python — один из нескольких языков, в которых легко писать самодокументированный код: код, который понятен без комментариев. В хорошем коде в Python многие методы читаются просто как предложения на английском языке.

Ваша задача при написании кода — тоже делать его максимально простым и лаконичным. Просто думайте, насколько ваш код будет легко читать, и вы начнёте двигаться в правильном направлении.

В Python принято писать легко читаемый код. Желательно, чтобы каждый метод целиком помещался на экран (длина метода — 20–30 строк). Это норма для всего Python-комьюнити. Если код можно улучшить, его нужно улучшить.

Лучший способ научиться писать хороший код — постоянная практика. Пишите много кода, изучайте чужой код, просите более опытных коллег сделать ревью вашего кода. И помните, что в тот момент, когда вы себе скажете «и так сойдёт», ваше развитие остановится.

Решать, какие сущности должны быть в программе

Вам нужно писать код, понятный для других программистов. Если 9 из 10 программистов при проектировании программы сделают в ней классы A, B и C, то и вам тоже нужно сделать в вашей программе классы A, B и C. Вы должны писать код, понятный для других.

Отличный, работающий, быстрый, нестандартный код — это плохой код.

Вам нужно изучать чужие проекты: это самый лучший, самый быстрый и самый лёгкий способ перенять всю мудрость, которая десятилетиями копилась в ИТ-индустрии.

И, кстати, у вас уже есть под рукой отличный, популярный, хорошо документированный проект — Python SDK. Начните с него.

Разбирайте классы и структуры классов. Думайте, почему одни методы сделаны статическими, а другие — нет. Почему у методов именно такие параметры, а не другие. Почему именно такие методы, почему классы называются именно так и находятся именно в таких пакетах.

Когда вы начнёте понимать ответы на все эти вопросы, вы сможете писать код, понятный другим.

Однако хочу предостеречь вас от разбора кода в методах Python SDK. Код многих методов был переписан с целью максимизации скорости работы — его читабельность под большим вопросом.

Правильно разбивать программу на логические части

Любую программу обычно разбивают на части или модули. Каждая часть отвечает за свой аспект программы.

Вот у компьютера есть системный блок, монитор, клавиатура, и это всё отдельные, малозависимые части. Более того, их взаимодействие стандартизировано: USB, HDMI и т.п. Зато если вы прольёте кофе на клавиатуру, вы можете просто помыть её под краном, просушить и пользоваться дальше.

А вот ноутбук — это пример монолитной архитектуры: логические части вроде и есть, но интегрированы гораздо сильнее. У Macbook Pro, чтобы почистить клавиатуру, нужно разобрать половину ноутбука. А пролитый на ноутбук кофе — повод заказать новый. Только не кофе.

1.3 Создание своих классов

Когда вы только начинаете программировать, важно начинать с малого — учиться создавать собственные классы.

Вы их, конечно же, уже создавали, но вам нужно учиться понимать, какие классы должны быть в программе, как они должны называться, какие у них должны быть методы. И как они должны друг с другом взаимодействовать.

Список сущностей

Если вы не знаете, с чего начать, начните с начала.

В самом начале проектирования программы вы можете просто выписать на листик список сущностей (объектов), которые должны быть в программе. А потом запрограммировать их по такому принципу: каждая сущность — отдельный класс.

Пример

Допустим, вы хотите написать игру в шахматы. Вам понадобятся такие сущности: шахматная доска и 6 типов фигур. Фигуры ходят по-разному, имеют разную ценность — логично, что это отдельные классы. И вообще, в самом начале, чем больше классов — тем лучше.

Встретить программиста-новичка, который вместо двух классов написал бы десять — большая редкость. Вот вместо десяти написать два, а то и один — это новички любят. Так что больше классов, господа программисты. И ваш код станет понятнее всем, кроме, возможно, вас 😛

Шахматы

Допустим, мы решили писать классы для шахмат: как бы эти классы выглядели?

Шахматная доска — это просто массив 8 на 8? Лучше сделайте для неё отдельный класс, который внутри хранит ссылку на массив. Тогда в класс «шахматная доска» вы сможете добавить много полезных методов, которые, например, проверяют, что клетка пустая или занята.

В общем, в начале всегда можно руководствоваться принципом: Программа имеет разные Сущности, а у Сущности есть тип. Вот этот тип — это и есть класс.

Комментарии (6)
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Anonymous #6475281 Уровень 17
5 марта 2026
Однозначно лайк за правильный выбор марок авто))
Vlad Уровень 15
25 октября 2025
Часто, на рекомендациях к собеседованиям и у дургих программистов на стримах можно услышать: - "Не лезь в чужой код, на существование этого кода были причины" - "Если не хочешь чтоб тебя погнали за шею, не говори ничего о рефакторинге чужого кода" - "Работа программиста - это копание в говнокоде, его понимание, и готовность нести тот же ГовноКодистый стиль дальше по проекту" Поэтому, пока что, отношусь с сомнением к части:"Правильный и непонятный код улучшать не получится. Его останется только выбросить." - может вернусь сюда позже чтоб дополнить свой ответ
Vladimir Уровень 1
28 декабря 2024
>Правильный и непонятный код улучшать не получится. Его останется только выбросить. Очень спорные утверждения, как и во всех вводных статьях.
Денис Уровень 37
30 декабря 2024
К сожалению достаточно правдивое утверждение. Одно из ключевых требований к хорошему коду это читаемость и поддерживемость, при том желательно специалистом любого уровня. Сложно написанный код зачастую проще переписать с нуля чем рефакторить. Ну или его просто предпочитают не трогать - работает же и пусть работает.
Mongoose Уровень 16
24 декабря 2025
Дедлайн - угу, угу, давай переписывай )))
Денис Уровень 37
24 декабря 2025
Мне кажется ты не вполне понимаешь о чем пытаешься рассуждать, но попробую объяснить: В коде не редко попадаются куски написанные плохо, давно, непонятно кем, и тем не менее работающими. На таком коде висит ответственность, как финансовая так порой и более серьёзная. Например обработка датчика температуры в рефриджираторе. Напортачил с ним и кто-то шырнётся испорченным инсулином. Ну или пример с Boeing 737 max и датчиком угла атаки тоже показательный, хотя там больше вопросы к менеджменту и QA отделу. Потому без веских причин такой код предпочитают не трогать, а если и трогать то переписывать полностью, и уже качественно, с полным утверждением бизнес логики. Просто отрефачить такой код может привести к нежелаемым последствиям. Но это частные случаи, пусть и не единичные.