Классы и ООП: зачем, а главное — когда использовать, а когда нет?

Question

[mRelby]

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

Прочитав и просмотрев не один десяток различных статей и видео на YouTube о Python в частности об ООП, я так ни разу и не услышал ответа на вопрос, который как мне кажется достаточно важен:
зачем, а главное - когда следует использовать классы, а когда достаточно будет написать несколько простых функций.

Предположим. Я хочу написать бота для tg, который бы отправлял пользователю видео, скачанное с... ну, например, с КиноПоиск.
То есть, пользователь отправляет боту ссылку на фильм, а бот делает всё необходимое и в итоге присылает ему видос (трейлер) к этому фильму.

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

Буду признателен, если кто-то объяснит мне всё это простыми словами.

п.с. если навёл плохой пример - предоставьте свой пример, и объясните, что да как.

Спасибо.

Comments

[Алан Гибизов]

Много букв

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

Для этого используют, например, базу данных. Это неплохой способ.

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

В вашей программе есть функция, добавляющая пользователя в базу; убирающая функция тоже есть; ищущая и получающая сведения.

Также есть таблица для фильмов; таблица для серверов; и т.п.

Класс пользователей просто объединяет в себе таблицу и функции, относящиеся к пользователям. Объекты класса - это строки в базе данных. Каждый объект имеет методы - те самые функции.

То-есть класс и его инстансы - это более удобное для программиста представление данных и относящихся к ним функций. Они представлены не как гроздь разнообразных переменных и функций, а как некая сущность с параметрами и способностями. Теперь вы можете просто взять обьект-пользователя и всё сразу при нём- и имя, и id, и способности ченьть сделать с ним (изменить, удалить, в общем- что надо).

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

Короче, когда вы через годик вернетесь к своей программе, вы увидите не грозди забытых функций и переменных, вспоминать которые долго и больно, а внятную структуру: вот класс пользователей. Вот класс фильмов. Вот класс серверов. Они обращаются один к другому стандартным образом. Всё понятно. Надо что-то поменять? Добавить? Делаем новый класс на основе вашего, добавляя ему метод или параметр. Надо вместо фильмов - книги? Пишем класс книг, остальное остается так же.

Становится легче в будущем работать с этим всем.

Answer 1

[Армянское Радио]

Все эти классы, фабрики, абстракции и прочие умные слова нужны для того, чтобы программист мог управлять сложностью создаваемой им программы. Наше сознание хранит в среднем 7 различных сущностей, так что разрезав задачу на законченные куски - объекты, мы даем себе и коллегам возможность уменьшить количество сущностей, которые нужно держать в голове.

Далее, программа, порезанная на части, допускает замену одних частей на другие. Это дает возможность разрабатывать программу, постепенно наращивая сложность и заменяя ненаписанные еще куски затычками, тестировать ее, заменяя сложную реализацию чего-то предсказуемой затычкой и переносить готовые куски кода с место не место, без переписывания заново всей программы в случае небольшого изменения логики.

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

Answer 2

[Ernest Faizullin]

Во первых принцип OOP нужен когда вы хотите как перфекционист разложить все по полочкам, во вторых когда в проекте больше одной-двух сущностей и их экземпляров

Например, сервис вопросов и ответов

questions (hasMany answers)
    answers (belongsTo question)
        likes (belongsTo answer)
        comments (belongsTo answer)

Чтобы не плодить повторяющийся код, создается модель (шаблон) с помощью которой можно создавать необходимое количество экземпляров. Во всех фреймворках есть логика для связей между этими экземплярами по принципу hasMany/belongsTo

Еще есть понятия интерфейсов, абстракций и описание их работы в сервис-провайдерах (это надо гуглить, смотреть примеры).

Таким образом мы структурируем код и данные с которыми работает код. И это все must have, если ты хочешь показать свой скилл

Answer 3

[Adamos]

Простая аналогия разницы между процедурщиной и ООП.

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

Так вот, после определенного объема и сложности работать с "книжкой" (например, найти конкретную таблицу и сверить ее данные) тяжко даже автору.

Answer 4

[Сергей Водаков]

зачем, а главное - когда следует использовать классы, а когда достаточно будет написать несколько простых функций.

Зачем - здесь уже ответили, ради структурирования кода и упрощения поддержки, масштабируемости и автоматизированного тестирования.
Когда - если вы пилите свой проект, то тогда, когда почувствуете что вам это нужно. Когда поймете, что процедурный код не можете удержать в голове. Тогда вы полностью перепишите свой код в ООП стиле и у вас не будет больше возникать таких вопросов. Естественно, если у вас маленький проект, который умещается в несколько процедур, то вы к этому не прийдете, но так там оно и не нужно.
А вот если вы работаете в команде, то уже имеющаяся кодовая база вам всё покажет. Сложно писать процедурно часть проекта построенного на ООП.

Answer 5

[Дмитрий]

https://en.wikipedia.org/wiki/Fundamental_theorem_...