Зачем нужны class в Python?

Question

[Djus1]

У меня есть чувство как будто я что-то не понимаю и туплю.

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

Вот пример кода:

class ...
    def ...
    def ...
    def ...

Зачем тут нужен класс? Я гуглил, вылазит ООП, с которым всё становится только сложнее.

Не могли бы вы простым языком объяснить, где я должен использовать классы и с какой целью?

Желательно с примером :)

Comments

[aleks-th]

В тысячах учебников это объясняется с примерами. Перепечатывать примеры смысла нет никакого. Какие примеры ты читал и что не понял ?
Это во первых

И да использовать class ты нигде не должен, и можешь все на функциях написать., Никто не запрещает.
Это во вторых

[Djus1]

aleks-th,
Большинство примеров это абстрактные пекари, с их печами. Идеально было бы увидеть до и после. Код до использования класса и после, на сколько он сократился и упростился и т.п

Я сейчас собираюсь начать "большой проект" и хочется понять базу, до этого...

Answer 1

[Александр]

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

Comments

[Djus1]

Сейчас я разделяю свой код на различные файлы, это заменяет классы?

[aleks-th]

Djus1, нет

[Hemul GM]

Djus1, класс нужны не для группировки функций, а для работы ООП. Когда конкретный класс содержит в себе нужную ему информацию для работы.

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

[Александр]

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

Answer 2

[Dimonchik]

Я гуглил, вылазит ООП, с которым всё становится только сложнее.

сам спросил - сам ответил ))

ну давай погуглим зачем нужен ООП

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

https://habr.com/ru/articles/148015/

короче - для скриптов на одно-два действия классы нафиг не нужны, даже вредны - больше кода

но на более менее маленьком, но уже проекте с кучей файлов - ты взвоешь

впрочем, есть Go который ООП не любит ))) но при этом насыщен структурами оооочень по коду на классы похожими - хотя это, конечно, далеко не одно и то же

Answer 3

[Vindicar]

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

А классы нужны для случаев, когда у тебя есть набор данных (состояние) и поведение, относящиеся к одной сущности.
Наглядный пример: файл. У него есть состояние - скрытые данные, например, дескриптор файла, правила чтения/записи, и т.п. вещи. И у него есть поведение - операции чтения, операции записи, закрытия и т.п.
Если эти операции оформить как функции, то им придётся передавать всё состояние файла явно, через параметры. А значит, программисту, который будет работать с файлом, придётся быть в курсе, как файл устроен внутри. Ему будет сложнее писать программу.
Если же мы обернём файл в объект, ситуация меняется. Теперь это состояние оказывается скрыто внутри объекта. Программисту достаточно иметь в своём распоряжении объект (экземпляр класса), и знать его "видимые снаружи" операции и свойства, а от внутреннего устройства он может абстрагироваться и вообще о нём не думать. Это здорово упрощает жизнь.

Comments

[res2001]

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

Это не так. Принцип черного ящика прекрасно работает в процедурных ЯП и используется повсеместно - просто используешь предоставленный интерфейс и не лезешь внутрь. Возьмите, например, Linux API и его функции работы с файлами - вы же не знаете, что там внутри делается, просто вызываете read/write и передаете файловый дескриптор и не запариваетесь о кэшировании, о том, какая файловая система ни диске и т.п. вещах. Вполне себе ООП подход.

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

Сам питон и вся его система классов реализована на Си.

[Vindicar]

res2001, ну да, только вот файловый дескриптор есть не что иное, как некий непрозрачный для нас селектор, позволяющий драйверу файловой системы выбрать правильный файловый объект для выполнения операции. Т.е. файловый дескриптор - это, по сути, эквивалент this, если не по механике, то по смыслу. =)

А насчёт ООП без ООП средств в языке - ну так я и не утверждаю, что это невозможно. Опять таки, если я верно помню, те же драйверы ФС с точки зрения ядра линукса - это структуры в стиле C с указателями на функции типа open, read, write, close, и т.п. Это, по существу, полиморфизм без ООП инструментов в языке.

Answer 4

[Алексей Черемисин]

Вы очень даже правы, часто классы мешают, чем помогают.
И на питоне можно писать без классов. Но можно и в стиле ООП, с классами.

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

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

Как примеры функционального подхода:
- язык clojure - классов фактически нет, есть функции и данные, причем данные - иммутабельные.
- язык java - введением функциональшины () и datа-классов (фактически набор данных)
- фреймворк reactjs с его хуками
- куча фреймворков для java (sparkjava и прочие)
- фреймворк flask для python, ну и туда же aiohttp
- язык javascript

Ну и сам python позволяет писать в полностью функциональном стиле!
Используйте аннотации, asynio и функциональные элементы языка.

А я рекомендую присмотреться и к clojure.

Comments

[Roman K]

Без классов в питоне писать, к сожалению, нельзя, потому что структуры (struct, record, dataclass) всё равно придётся объявлять через class.

Ну и сам python позволяет писать в полностью функциональном стиле!

Не позволяет. Язык без полноценной поддержки лямбд не может позволить писать в функциональном стиле

[Алексей Черемисин]

Roman K, ну, лямды имеем же. И если приноровиться, то можно и в полностью функциональном. Используем классы-структуры, как хранилища данныx, и не задумываемся, что они классы. С другой стороны, если глянуть поглубже в эту клоаку, то окажется, что класс это тoже dict :)

[Roman K]

Алексей Черемисин, плохая шутка

[Алексей Черемисин]

Roman K, какме уж тут шутки __dict__ аттрибут у любого класса, и не только...

[Roman K]

Алексей Черемисин, какая разница, как оно там под капотом реализовано? Классы в питоне можно представить типами, словари - нельзя. TypedDict не в счёт, это исчадье ада. Есть даже локальный мем - dict typed (примерно как и stringly typed). Иными словами, это всё write-only программирование. Достоинство ФП прежде в том, что у программиста есть сильная система типов. Все ФП языки базируются на хорошей системе типов. А не использовать классы в питоне потому что "это классы" и вместо них использовать словари - это брать худшее из двух миров.

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

[Алексей Черемисин]

Roman K, Ну вот тут не соглашусь совсем. Взять тот же clojure, типов практически нет, кроме примитивных (точнее они есть, но...), нет и проверки на типизацию.
Есть сторонние инструменты, преобразования примитивных типов из одних в другие и их валидацию. Все остальное - на волю программиста.
Другими словами, язык - опциоанльно типизированный.
И это не мешает ему быть хорошим помраньоном в java-мире.
Да и вообще, практически все современные ФП мало типизированы, что и делает их очень гибкими.

[Алексей Черемисин]

Roman K, Ну и про лямбды (и замыкания) в питоне - какая проблема делать

def func(i):
  def inner():
     return i+1
  return inner

[Roman K]

Алексей Черемисин, это не лямбда. Почитай, что такое лямбды (анонимные функции)

[Алексей Черемисин]

Roman K, это замыкания :) и лямбды я знаю что такое

l = lambda x: x + 10
d = [1,2,3,4,5]
[l(i) for i in d]
#=> [11, 12, 13, 14, 15]
>>>

[Roman K]

Алексей Черемисин, здорово. А теперь давай лямбду на две строки

Answer 5

[Wan-Derer]

Классы позволяют описать объекты реального мира, а также разделить (классифицировать) одинаковые функции разных объектов, которые выполняются по-разному.
Допустим, ты создаёшь зоопарк. Там есть разные животные. Для любого животного характерны одинаковые по названию функции ("есть", "говорить", "перемещаться" и пр.), но выполняемые по-разному. Поэтому для разных животных ты получишь разный результат выполнения функций с одинаковыми именами:

frog.speak()     # "Ква-ква!"
horse.speak()    # "И-го-го!"

Answer 6

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

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

Так вот.

• Таблица со своим собственным именем - это тип данных.
  
• Заголовок таблицы это класс, описывающий этот тип данных.
  
• Строки таблицы с данными - это экземпляры класса.
  
• Колонки таблицы это атрибуты.
  
• Формулы, протянутые на колонки таблицы, это методы класса.
  

Это очень-очень грубо.

Comments

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

Это не значит, что всё надо разложить в классы. А то иногда людям, которые держат в руках молоток, всё вокруг кажется гвоздями.

Answer 7

[mayton2019]

Классы удобны когда все функции объединяются общим контекстом. Например подключение к БД.
Или класс - клиентское окно где можно рисовать графику. Можно кодить и без классов на голых
функциях (такое тоже практируется) но тебе придется одним параметром всегда передавать
контекст.

Использование классов (объектов) для хранения состояния - это признак зрелости исходного кода.