Мимо вкатун в программирование, вчастности Пайтон. Аноны, подскажите кто такой этот ваш ООП?!?!?!? Читал, смотрел, +/- понял, но до конца не понял зачем это надо то. Что такого можно с ООП? Ведь ровно тоже самое можно организовать через функции. Мб есть работа(пример проэкта) с которой без ООП вообще никак или будет адово сложно.
>>3066590 (OP) ООП делает проще понимание и организацию кода. Если в обычной процедурке у тебя просто куча функций которые принимают какие-то данные, то в ООП данные и методы для них напрямую связаны. Например если у тебя скрипт 5к строк, то ООП не обязателен, иногда даже проще без него. Но на больших проектах без ООП нельзя, да и строятся они на фреймворках. Чтобы мыслить в объектах на програмном уровне нужна некоторая сноровка и опыт.
В объект можно убрать вообще все что угодно - любые данные которые ты потом будешь передавать в методы(функции). Различная организация объектов позволяет именно что создавать гибкие модульные системы тогда как процедурка это скорее про скрипты.
У нас на проекте, например, был один говнокодер который в ООП не врубался, а там был импорт одного огромного файла с кучей данных так эта мартышка нагородила нечитабельного во вложенных массивах массив-массив-массив-массив-массив-нужныеДанные везде блядь. Потом пришлось переписывать и убирать этот огромный файл в объект и уже у этого объекта проситт данные в нужном нам виде одним простым методом, заодно прописали ему валидацию через нужные проверки при инициализации объекта и нормализацию через шаблон прототип потому, что вторая мартышка не умеет присылать данные в полном виде и у нее постоянно ошибки из-за отсутствия нужных полей, а городить на каждый пук условие это ебнешься сколько копипасты будет. Ей похуй, потому что дура с клавой, а у нас импорт валится из-за этого.
Объяснять рили очень долго можно и без толку. Надо самому на первых порах стараться писать именно в ООП, тогда начнешь понемногу врубаться в мощь этого подхода.
>>3066590 (OP) > Что такого можно с ООП? Ведь ровно тоже самое можно организовать через функции. Мб есть работа(пример проэкта) с которой без ООП вообще никак или будет адово сложно.
Ну например фреймворк, лол. Тяжело сделать фрйемворк без ООП или хотя бы без псевдо ООП. Производителям фроеймворка нужно работать с кодом который ТЫ напишешь, а они даже не знают какой он будет. И это рил тяжело без ООП сделать
>>3066590 (OP) Представь, что класс - это кубик лего, а его устройство внутри - это то, из чего сделан кубик лего. А из нескольких кубиков лего можно собрать кучу вещей. На основе одного кубика лего, можно сделать такой же, но расширенный по функциональности кубик лего - это наследование
>>3066590 (OP) Ещё одна парадигма программирования. То есть подход к решению задачи. Основная идея которой инкапсуляция, то есть мы представляем что некоторый набор данных знает как себя редактировать. Всё нах тема закрыта. И ещё в ооп всё есть объект, то есть теоретически когда к тебе прилетает некий объект, он должен знать как себя редактировать, это называется поздним связыванием. Всё есть объект это блять даже цикл объект сам по себе.
Наследование и прочая поебота с интерфейсами и т.д это некоторое вырождение этой идеи из-за того, что позднее связывание не совсем безопасно. Сокрытие блять не относится к ООП как таковому, но на собеседовании упомяни.
Вот тебе пару парадигм для развлечения "Всё есть файл" и "Структурное программирование".
Ещё ты должен уяснить что парадигмы (подход к решению задачи) не обязаны конфликтовать друг с другом, а могут вполне сочетаться. Но да бывают случаи когда они конфликтуют.
Пример сочетания ООП и Обобщённое программирование.
На С хотя в языке не зашиты такие возможности по умолчанию, вполне реально использовать ООП и Обобщённое программирование.
Можешь немного подзаебаться и понять что такое побочный эффект.
>>3082430 Продолжу небольшой момент, про позднее связывание. В изначальной идеи имелось в виду, не совсем то, что сейчас называют поздним связыванием, ака плагины, аддоны, они же расширения, дополнения.
Представь, что у тебя есть клиент-серверное приложение. Твой клиент запрашивает некий объект и вызывает у него некий один метод API согласованный с протоколом твоего приложения. Вот тут и вся магия к тебе должен прилететь именно объект с реализацией метода если это ЯВМ языковая виртуальная машина то управляемый байт-код, если нет то неуправляемый и вот этот код должен будет исполнится. Да сторонний и теоретически он твоего клиента уже ебёт как хочет. В каком-то смысле так работает JS поэтому движки браузеров работают типа как в режиме песочницы не допуская исполнять системные вызовы операционной системы, а могут и завести баги не специальные и не очень.
>>3082499 Не знаю как в других языках, в JS всегда был объект window через который можно связывать компоненты кода друг с другом. По сути тебе даже не надо никуда лезть, там хранятся все нужные методы с доступом даже из других скриптов.
>>3082435 >Фреймворк - это всего лишь набор готовых решений для типовых задач, исполненный в любом тебе понравившимся стиле.
Нет, нихуя. Это ты библиотеку описал. Фреймворк это в первую очередь inversion of control. Библиотека это когда ты запускаешь в своем проекте ИХ код, а фреймворк это когда он запускает ТВОЙ код.
Вообще в ООП появляется необходимость когда у тебя большие команды пишущие большие проекты.
В попытках изучить ООП на пайтон - начал писать бота для телеграм. В принципе много проясняется. Немного глянул за магические методы, но нужно будет это более детально изучить на досуге
Написал пру своих библиотек текстами, класса и их методами. В целом норм, капитально подгимает читаемость, модульность.
* хотя юзаю это немного криво. Создаю не новые экземпляры класса, а тупо использую декоратор метода класса, важные логи кидаю в файлы, рабочие переменные в словарь или лист. Все изза опосения что при большом колличестве посетителей забьет помять, увеличится нагрузка на серв, да и хз... Надо будет попробовать с экземплярами какуюто логику организовать
>>3082782 Я вообще не правильно распарсил контекст, но если ты изменяешь глобальные переменные - хуйну тебя по рукам. Точно так же, как и за синглтон где он не нужен.
>>3083129 Чел, во всём джава ынтерпрайзе все бины - это де-факто глобальные переменные, которые изменяются. С добрым утром. И вообще неизменяемых синглтонов я не видел.
>>3082845 Библиотека это единица развёртывания приложения. Внезапно набор готовых решений поставляется в виде библиотек.
> ИХ код, а фреймворк это когда он запускает ТВОЙ код. Типа написал всяких функций с обратным вызовом, теперь можно сказать что фреймворк? А до этого нет?
Ты опять наверное не понял сути фреймфорка. Суть фреймворка предоставить тебе некий функционал , на базе которого ты строишь своё приложение, попадаешь под его анальное рабоство.
Поэтому умные люди бизнес-логику отделяют от фреймворком по средствам интерфейсов.
>>3084037 Того блять, то что вкусные для тебя всякие коллекции типа List, Hashtable, Map и прочаяя поебота тоже являются фреймворками.
Ты же не написал собственную реализацию всего этого говна для себя?
Я к тому что библиотеки и фреймворки это не раздельный друг к другу вещи. Стой лишь разницей что фреймворк может быть разбит на несколько библиотек, а ты в своём приложение используешь не весь набор готовых решений, поэтому подключаешь только те библиотеки которые тебе нужны.
Это всего лишь принцип работы с фреймворками, но не сам фреймворк. Нужен когда тебе уже один фреймворк не нужен нахуй и тебе требуется наименее болезненно сесть на другой хуй фреймворк.
Работал например с .net freamwork и хуяк тебе нужно партировать на .net core.
>>3084060 >.NET фреймворк это буквально хуйня которая запускает написанный тобой говнокод
>>3084055 >Того блять, то что вкусные для тебя всякие коллекции типа List, Hashtable, Map и прочаяя поебота тоже являются фреймворками.
Это буквально библиотека. Типа какой-нибудь буст от крестов где даются кучу разных коллекций это же не фреймворк. Буст хоть и огромная библиотека на базе которой пишут много кода, но фреймворком не является.
Вообще этот спор реально куда-то далековато ушел. Он изначально был про то что тип зачем нужно ООП, и что без него нельзя сделать. На самом деле ответ что сделать без него все можно, но некоторые вещи прям как будто делаются лучше в ООП. В командной разработке крупных проектах ООП в целом доминирует потому что там удобнее писать такой код. Типа так он был Open-Closed, чтобы ты мог расширять функционал модуля соседа напрямую в его модуль не коммитя