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