Прототипно-ориентированное программирование. Сейчас в википедии пишется что мол это стиль ооп, но отмечено что это не проверенная информация. На самом деле все с точностью наоборот. Ты можешь реализовать ООП на ПОП, но не наоборот. Идея в том что даже банальное создание класса, выглядит местами избыточным. Это как когда тебе нужно сделать банан, а ты создаешь джунгли, обезьян и только потом банан. Кроме этого есть языково-ориентированное программирование (DSl надстройки и тд). Это считай вообще лучший вариант замены ООП, но есть минус) (куда же без него) оно требует высокой квалификации разработчика, чтобы реализовать dsl. Мало того что большинство даже не знает что такое dsl (это не их специализация. это нормально), так для того чтобы это реализовать, нужен спец разбирающийся с синтаксическом анализе, работе транспиляторов и тд. + Добавь к этому то что обучить ооп новичков в разы проще. Посмотри на JS) Это прототипно-ориентированный язык, но в него добавили классы как синтаксический сахар, просто чтобы не смущать новичков которые учили ООП в университете)
1:27 Функциональное программирование =/= процедурное программирование. Тот же котлин, поддерживает значительное количество концепций из функционального программирования, такие как high order functions (+ context receivers), extensions, Unit как возвращаемый тип, immutability, tailrec, deep recursion. Или это все заслуги ООП? Монады, функторы, каррирование, функциональные типы? После просмотра видео у человека не знакомого с функциональной парадигмой может сложиться впечатление что, ФП - это как ООП, только без классов. Концепции из ФП могут отлично дополнять ООП, котлин отличный тому пример. Зачем упоминать ФП в видео не разобравшись в теме, вводя людей в заблуждение?
На самом деле на этот вопрос не ответа, но на данный момент ОПП чувствует себя хорошо, при всех его недостатках. 5:12 В ООП языках как правило реализовано событийно-ориентированное программирование. 5:52 Геттеры и сеттеры защищают объект от неправильного состояния, так же расширяют возможности наследования. В котлине под капотом происходит тоже самое, это просто синтаксический сахар, проблемы нет.
То, что ООП себя хорошу чувствует, не значит, что у него нету минусов и оно не поддается критике Событийно-ориентированное программирование зачастую реализовано в фрейворках и библиотеках, я надеюсь ты имел ввиду их) Бебро сказал все правильно. Он не говорил, что их убрали, он сказал, что "от них СИНТАКСИЧЕСКИ" отказались", потому что по сути они являются переопределением функционала, которого можно достичь способами, не порождающими кучу ненужного кода
касательно геттеров и сеттеров все верно, но в видео это вменяется в вину ООП, хотя это проблема конкретных реализаций. Это все равно что сказать "Птици летают, но делают это очень плохо - курицы едва ли могут оторваться от земли."
Я начинающий в программировании, но моё мнение чтоб ответить на вопрос зачем ООП, то нужно попробовать написать программу на чистом С, где вообще нет ООП, на С++ где ООП уже есть, и на С#, где ООП уже другого уровня. И тогда станет всё на свои места в голове)
Ну как сказал Герберт Шилдт, умение программировать это наука, а умение делать код сболанстрованым это уже искусство, ну вроде того, там он более заумно описывал)
Новичок в програмировании и меня скорее путает всё это драбление на файлы, функции, классы и т.д. Порой они реально полезные, но я не вижу смысла их пихать на 3 строчные куски кода
тебя никто и не заставляет это делать просто в быдловузах не учат правильно использовать ооп и прогу на 3.5 строчки заставляют писать на ооп на 100500 строк ты не сможеш написать, потому что еще туп и тупо нет столько времени поэтому тебе и кажется, что это б есполезная херня
Согласен полностью. Писать легко на ООП с нуля, а вот обслуживать, особенно то, что сам не писал настолько большая проблема, что тестирование ПП стало самостоятельной профессией. Хз что там понаследовано, хз что там переопределено, можно ли что-то дописывать, улучшишь в одном месте, отвалится во многих - это ООП. Вот и получается проблема как оттестировать тонны ООП-кода, когда внесенное изменение вдруг повлияло на половину фукционала (причем к удивлению того, кто дал команду изменить, самого изменяющего и всей команды). ООП - источник вечного дебагинга.
"Геттеры и сеттеры являются ненужным усложением кода" - так можно сказать только о тех геттерах и сеттерах которые оборачивают прямой доступ к полю, но даже в этом случае, они обезопашивают от будущих изменений. Простой пример: Представим синглтон класс Calendar, имеющий публичное целочисленное поле currentDate, не имеющее геттеров и сеттеров. Задается значение currentDate в самом начале запуска программы, путём обращения к системе. В программе есть 100 обращений к currentDate, чтобы считать его значение. А теперь представим, что нам, как разработчикам приходят требования: Отныне 1) значение currentDate, должно приходить с бекенда, причем каждый раз. 2) изменять поле изнутри программы, как мы это делали на старте нельзя. Что делать? Удалять поле currentDate за ненадобностью, и писать метод getCurrentDate, в котором будет происходить запрос и получение данных со стороны бекенда. Теперь мы вынуждены пройтись по каждому из 100 предыдущих вызовов поля currentDate, и заменить вызовы поля на вызовы метода getCurrentDate. Видно, что при таком сценарии программа не восприимчива к будущим изменениям, чего можно было бы избежать используя геттеры и сеттеры. В случае с геттерами и сеттерами, при таком же сценарии пришлось бы удалить (уже приватное) поле currentDate за ненадобностью вместе с сеттером. В тоже время метод getCurrentDate достаточно переопределить, не нарушая заданную ранее сигнатуру метода. Поздравляю, теперь не нужно идти во все 100 мест вызова и менять код. P.S. Да, в видео сказано о том как проблема решена в котлине, однако важно понимать что в котлин классе используются не поля (field), а свойства (property). Язык позволяет не писать бойлерплейтные геттеры и сеттеры, создавая backing field за нас, однако язык позволяет переопределить геттер и сеттер для свойства, что позволяет избежать первого описанного сценария с использованием публичного поля. Иными словами котлин отличается синтаксически, но использует ту же концепцию геттеров и сеттеров, на чем был сделан слабый акцент в видео, что может ввести начинающих в заблуждение. Ну и вывод с учетом выше сказанного: геттеры и сеттеры не являются минусом ООП, напротив, они обеспечивают нам гибкость при дальнейших изменениях, и (о чудо) инкапсулируют (напомню что это один из принципов ооп) логику связанную с обращением к полю.
Я, как начинающий python разработчик, использую ООП по минимуму и большие проекты предпочитаю делить на микросервисы. Работал по профессии я всего около 6 месяцев и какое-то время (в том числе и сейчас) я на фрилансе. Сколько раз я пытался перейти на ООП и всегда это кончалось крахом. ООП выглядит прекрасно на примерах из жизни условные машины или животные. Но когда вещь касается взаимодействия с различными api, парсинга, конвертирования, запросов, я просто не понимаю зачем мне плодить лишние сущности и только усложнять себе код. ООП, классы я использую там где они действительно нужны, например при работе с базой данных, так как там хранятся реальные сущности, при работе с запросами по тому или иному url моего api, потому что запрос имеет определенные поля и так или иначе работает с сущностью. Если я понимаю, что проект разрастется, я делю его на микросервисы и не получаю путаницы с 15 открытыми файлами, чтобы понять суть программы. Не люблю языки, по типу Java и C#, которые насильно заставляют тебя писать в чистом ООП. Я не против классов, объектов, наследования и прочего, мне не нравится, когда подход, удобный для конкретных случаев, превращается в сверх идею, которая доминирует над проектом P.S. Полагаю, меня сейчас закидают камнями, но я считаю, что необходимо понимать, зачем использовать ту или иную вещь и делать это осознанно, а не делать что-то потому, что какой-то умный дядя 50 лет назад что-то там придумал P.P.S. И да вы можете, сказать что я так в никогда в жизни не стану успешным разработчиком, укажите на мой непрофессионализм и что я ничего не понимаю. Но я всего лишь студент с небольшим опытом работы и по сути разработка для меня это искусство и способ проявить свое желание созидать и творить
Я скоро планирую сделать видос. Хочу обратить внимание людей на то, что ООП не идеально и в некоторых случаях лучше использовать другие подходы Так что в этом плане согласен с тобой
Отходы от темы по типу шуток про интеграции и разбросы между Ауди и ваз сбивают внимание. это для Вас все понятно, а мы , чтобы все понять, пытаемся держать в голове много озвученных вами вещей одновременно, это сложно и так, а тут ещё и разбросы с интеграциями.
я делаю классы только когда мне нужно несколько раз сделать какой-то объект, например контекстное меню, я же не буду писать несколько раз один и тот же код, легче сделать объект, который ты уже будешь тыкать из основного огромного кода
Стоит начать с того, что функциональную парадигму используют в разработке высоконагруженных вычислительных систем, искусственном интеллекте и система обработки больших данных. А ООП используется в прикладном программировании и эта парадигма так популярна и так долго держит нишу, исключительно потому что всё в сфере прикладного ПО легко абстрагируется до классов и объектов, при этом код сохраняет логику естественного хода вещей. Здесь вопрос не крутости парадигм, а сфер применения. p.s. Вы путаете функциональное программирование со структурным
ООП ничего не усложняет. Просто предмет может быть сложным сам по себе. Код же пишется не ради кода, а для бизнеса, у которого есть процессы, сущности какие-то.
Можно тебя чуть-чуть поправить, ООП это не о структурировании кода. Это о структурировании данных. В этом и состоит главное отличие от остальных стилей (парадигм). Поддержка кода хоть в 1000 хоть в 10000 строк - не сложно если весь код оперирует с 5-6 типами данных. А вот когда количество вариантов данных разрастается, функциональная парадигма начинает давать сбои. Если брать твой пример с машиной, то ООП пытается описать все характеристики объекта И все действия которые можно с этим объектом произвести. Пока ты описываешь только машину (причем конкретный тип), то все ок, но потом ты захочешь описать этим же объектом к примеру трактор, и все, нужно полностью переделывать не только структуру данных, но все методы(функции для работы с ней). А когда количество вариантов разрастается, то кроме ООП вариантов то и не остаётся. Может слегка сумбурно получилось, но надеюсь идею я смог донести.
В примере про вампира и оружие нужен третий класс -- Damage или Hit, а оружие и вампир должны реализовывать интерфейсы IWeapon и IDamagable. Но вообще поддержу автора, ооп чаще всего не нужно, особенно в не умелых руках
Такое чувство, будто собраны все "фишки" ООП в кучу, но максимально абстрактно друг от друга + намеренно переусложнил логику примеров. Тот же пример дамагом - зачем то намеренно запутываешь лишней логикой про то, что удар это не урон и прочей философией. У вампира делаем метод дамаг, в методе дамаг он использует оружие, класс которого ему передали при инициализации к примеру. У оружия есть атрибут - дамаг(инт), когда у вампира вызываем дамаг, в метод передаем каким оружием (если его у вампира несколько разных) и кого бьём. В теле метода две строчки self.hp += weapon.damage enemy.hp -= weapon.damage И плов готов. И кстати все эти 4 атрибута изменяем через сеттеры (которые типа не нужны), в которых проводим необходимую логику валидации аргументов, перед тем как изменить состояние объектов. ненадо запутывать людей софистикой всякой) я ожидал услышать реальные подводные камни ООП, а не такую абстракцию и философию. И какой подход к организации кода не растит массу кода при добавлении новых фич? Это какой-то нонсенс вообще
Забыл добавить «опытный программист 1с») Так то да, но это упирается в то что работодатель старается сделать разработку как можно дешевле и нанимает слабых разработчиков, которые умеют только в процедурку
почему нельзя перенести метод урона в суперкласс, от которого будут наследоваться два (или более) объекта сабклассов (вампир и богатырь), и через код реюз пеиеписать его в сабклассе вампир таким образом, чтобы нанесенный урон плюсовался к хп объекта сабкласса?
Да не, на самом деле вариантов много, просто я говорил о том, что даже такая небольшая фишка как один класс будет реализована большим количеством кода и создаст кучу неявных связей Тут ничего не поделаешь увы
Я не хочу обидеть автора ,но он не поминает о чем снял видео.ООП - ЭТО ВЕРСТАК ДЛЯ СОЗДАНИЯ ИНСТРУМЕНТОВ! В дальнейшем с помощью этих инструментов можно будет строить дома. Один дом,два дома ,три дома,и даже четыре.Если вам будет не хватать инструментов при строительстве дома,вы всегда можете сделать его у себя на верстаке,или переделать инструмент,дополнить или расширить его.А самое главное такой верстак вы можете таскать собой,и строить дома где угодно.Сразу скажу,если у вас в планах построить скворечник,или собачею будку,то вам не нужен верстак.А вот если вы пойдете работать в организацию где стоят на заказ скворечники собачьи будки ,то там в скорей всего пользуются верстаком .Я не буду приводить пример,мне лень,но если попросите,я потом добавлю пример такого верстака,всем удачи)
Класс вампир должен иметь метод "высасывание жизни", который связан с методом "удар", и получать информацию о количестве высасывания жизни на основе количества нанесённого урона методом "удар". Это же элементарно. Зачем городить какую-то ересь?
Я хз как можно не юзать ООП. Это же . ну. ЭТО БАЗА. То что код всегда только растет, это наоборот хорошо, значит новый хорошо ложиться на старый, а значит код хороший. и изменять его легче. И новый код писать проще, не задумываясь о старом. И понимать объект пачкаМасла гораздо легче
Пробовал учить C++ он мне мозги взрывал своим ООП. Сейчас учу JS вот где идеальное ООП. Не нужно создавать дурацких классов. Просто сразу делаешь объект и нечего лишнего. Вообще не кому не рекомендую учить C++ напрочь желание программировать отбивает.
Учите python там есть функциональное программирование. Bebro после того как прочитал этот комментарий: Смотрите мое прошлое видео!!! Я: Смотрите мой комментарий под тем видео!!!
@@BeBr0 ну ФП говно ещё то на самом деле) по этому у фпшников такие зарплаты космические, никто с хорошим психологическим состоянием не согласился бы ни за что с таким говном работать как фп
как вообще создавать подобие объектов без oop?
делать это как в sql???
Идея в том, что ооп нужно не всегда
идея в том, что тебе не нужны объекты)
например как в си, берёшь крч структуру и теребишь её функциями
Прототипно-ориентированное программирование. Сейчас в википедии пишется что мол это стиль ооп, но отмечено что это не проверенная информация. На самом деле все с точностью наоборот. Ты можешь реализовать ООП на ПОП, но не наоборот. Идея в том что даже банальное создание класса, выглядит местами избыточным. Это как когда тебе нужно сделать банан, а ты создаешь джунгли, обезьян и только потом банан.
Кроме этого есть языково-ориентированное программирование (DSl надстройки и тд). Это считай вообще лучший вариант замены ООП, но есть минус) (куда же без него) оно требует высокой квалификации разработчика, чтобы реализовать dsl. Мало того что большинство даже не знает что такое dsl (это не их специализация. это нормально), так для того чтобы это реализовать, нужен спец разбирающийся с синтаксическом анализе, работе транспиляторов и тд.
+ Добавь к этому то что обучить ооп новичков в разы проще. Посмотри на JS) Это прототипно-ориентированный язык, но в него добавили классы как синтаксический сахар, просто чтобы не смущать новичков которые учили ООП в университете)
1:27 Функциональное программирование =/= процедурное программирование.
Тот же котлин, поддерживает значительное количество концепций из функционального программирования, такие как high order functions (+ context receivers), extensions, Unit как возвращаемый тип, immutability, tailrec, deep recursion. Или это все заслуги ООП?
Монады, функторы, каррирование, функциональные типы?
После просмотра видео у человека не знакомого с функциональной парадигмой может сложиться впечатление что, ФП - это как ООП, только без классов. Концепции из ФП могут отлично дополнять ООП, котлин отличный тому пример. Зачем упоминать ФП в видео не разобравшись в теме, вводя людей в заблуждение?
На самом деле на этот вопрос не ответа, но на данный момент ОПП чувствует себя хорошо, при всех его недостатках.
5:12 В ООП языках как правило реализовано событийно-ориентированное программирование.
5:52 Геттеры и сеттеры защищают объект от неправильного состояния, так же расширяют возможности наследования. В котлине под капотом происходит тоже самое, это просто синтаксический сахар, проблемы нет.
То, что ООП себя хорошу чувствует, не значит, что у него нету минусов и оно не поддается критике
Событийно-ориентированное программирование зачастую реализовано в фрейворках и библиотеках, я надеюсь ты имел ввиду их)
Бебро сказал все правильно. Он не говорил, что их убрали, он сказал, что "от них СИНТАКСИЧЕСКИ" отказались", потому что по сути они являются переопределением функционала, которого можно достичь способами, не порождающими кучу ненужного кода
касательно геттеров и сеттеров все верно, но в видео это вменяется в вину ООП, хотя это проблема конкретных реализаций. Это все равно что сказать "Птици летают, но делают это очень плохо - курицы едва ли могут оторваться от земли."
Похейть ещё шарпов.
Тогда обязательно подпишусь!
Я начинающий в программировании, но моё мнение чтоб ответить на вопрос зачем ООП, то нужно попробовать написать программу на чистом С, где вообще нет ООП, на С++ где ООП уже есть, и на С#, где ООП уже другого уровня. И тогда станет всё на свои места в голове)
Хороший видос, спасибо, хотя было бы интересно послушать более развернуто твои мысли по этому вопросу
Ну как сказал Герберт Шилдт, умение программировать это наука, а умение делать код сболанстрованым это уже искусство, ну вроде того, там он более заумно описывал)
Новичок в програмировании и меня скорее путает всё это драбление на файлы, функции, классы и т.д. Порой они реально полезные, но я не вижу смысла их пихать на 3 строчные куски кода
тебя никто и не заставляет это делать
просто в быдловузах не учат правильно использовать ооп и прогу на 3.5 строчки заставляют писать на ооп
на 100500 строк ты не сможеш написать, потому что еще туп и тупо нет столько времени
поэтому тебе и кажется, что это б есполезная херня
позже увидишь
Согласен полностью. Писать легко на ООП с нуля, а вот обслуживать, особенно то, что сам не писал настолько большая проблема, что тестирование ПП стало самостоятельной профессией. Хз что там понаследовано, хз что там переопределено, можно ли что-то дописывать, улучшишь в одном месте, отвалится во многих - это ООП. Вот и получается проблема как оттестировать тонны ООП-кода, когда внесенное изменение вдруг повлияло на половину фукционала (причем к удивлению того, кто дал команду изменить, самого изменяющего и всей команды). ООП - источник вечного дебагинга.
Для этого есть clean architecture, solid и тому подобное
С точностью до наоборот!
"Геттеры и сеттеры являются ненужным усложением кода" - так можно сказать только о тех геттерах и сеттерах которые оборачивают прямой доступ к полю, но даже в этом случае, они обезопашивают от будущих изменений. Простой пример:
Представим синглтон класс Calendar, имеющий публичное целочисленное поле currentDate, не имеющее геттеров и сеттеров. Задается значение currentDate в самом начале запуска программы, путём обращения к системе. В программе есть 100 обращений к currentDate, чтобы считать его значение.
А теперь представим, что нам, как разработчикам приходят требования:
Отныне
1) значение currentDate, должно приходить с бекенда, причем каждый раз.
2) изменять поле изнутри программы, как мы это делали на старте нельзя.
Что делать?
Удалять поле currentDate за ненадобностью, и писать метод getCurrentDate, в котором будет происходить запрос и получение данных со стороны бекенда. Теперь мы вынуждены пройтись по каждому из 100 предыдущих вызовов поля currentDate, и заменить вызовы поля на вызовы метода getCurrentDate.
Видно, что при таком сценарии программа не восприимчива к будущим изменениям, чего можно было бы избежать используя геттеры и сеттеры.
В случае с геттерами и сеттерами, при таком же сценарии пришлось бы удалить (уже приватное) поле currentDate за ненадобностью вместе с сеттером. В тоже время метод getCurrentDate достаточно переопределить, не нарушая заданную ранее сигнатуру метода. Поздравляю, теперь не нужно идти во все 100 мест вызова и менять код.
P.S. Да, в видео сказано о том как проблема решена в котлине, однако важно понимать что в котлин классе используются не поля (field), а свойства (property). Язык позволяет не писать бойлерплейтные геттеры и сеттеры, создавая backing field за нас, однако язык позволяет переопределить геттер и сеттер для свойства, что позволяет избежать первого описанного сценария с использованием публичного поля. Иными словами котлин отличается синтаксически, но использует ту же концепцию геттеров и сеттеров, на чем был сделан слабый акцент в видео, что может ввести начинающих в заблуждение.
Ну и вывод с учетом выше сказанного: геттеры и сеттеры не являются минусом ООП, напротив, они обеспечивают нам гибкость при дальнейших изменениях, и (о чудо) инкапсулируют (напомню что это один из принципов ооп) логику связанную с обращением к полю.
Спасибо за такой большой коммент
Да, ты прав абсолютно, наверно стоило поподробнее остановиться на геттерах и сеттерах
Я, как начинающий python разработчик, использую ООП по минимуму и большие проекты предпочитаю делить на микросервисы. Работал по профессии я всего около 6 месяцев и какое-то время (в том числе и сейчас) я на фрилансе. Сколько раз я пытался перейти на ООП и всегда это кончалось крахом. ООП выглядит прекрасно на примерах из жизни условные машины или животные. Но когда вещь касается взаимодействия с различными api, парсинга, конвертирования, запросов, я просто не понимаю зачем мне плодить лишние сущности и только усложнять себе код. ООП, классы я использую там где они действительно нужны, например при работе с базой данных, так как там хранятся реальные сущности, при работе с запросами по тому или иному url моего api, потому что запрос имеет определенные поля и так или иначе работает с сущностью. Если я понимаю, что проект разрастется, я делю его на микросервисы и не получаю путаницы с 15 открытыми файлами, чтобы понять суть программы. Не люблю языки, по типу Java и C#, которые насильно заставляют тебя писать в чистом ООП. Я не против классов, объектов, наследования и прочего, мне не нравится, когда подход, удобный для конкретных случаев, превращается в сверх идею, которая доминирует над проектом
P.S. Полагаю, меня сейчас закидают камнями, но я считаю, что необходимо понимать, зачем использовать ту или иную вещь и делать это осознанно, а не делать что-то потому, что какой-то умный дядя 50 лет назад что-то там придумал
P.P.S. И да вы можете, сказать что я так в никогда в жизни не стану успешным разработчиком, укажите на мой непрофессионализм и что я ничего не понимаю. Но я всего лишь студент с небольшим опытом работы и по сути разработка для меня это искусство и способ проявить свое желание созидать и творить
Я скоро планирую сделать видос. Хочу обратить внимание людей на то, что ООП не идеально и в некоторых случаях лучше использовать другие подходы
Так что в этом плане согласен с тобой
ООП в python’е, рассмешил
@@saomoon что смешного?
@@chademap1071 то, на каком оно там уровне, я сам с пайтоном работал около полугода и имею опыт с таким говнецом
@@saomoon что не так с ооп в питоне?
Отходы от темы по типу шуток про интеграции и разбросы между Ауди и ваз сбивают внимание. это для Вас все понятно, а мы , чтобы все понять, пытаемся держать в голове много озвученных вами вещей одновременно, это сложно и так, а тут ещё и разбросы с интеграциями.
Учту, спасибо)
я делаю классы только когда мне нужно несколько раз сделать какой-то объект, например контекстное меню, я же не буду писать несколько раз один и тот же код, легче сделать объект, который ты уже будешь тыкать из основного огромного кода
Стоит начать с того, что функциональную парадигму используют в разработке высоконагруженных вычислительных систем, искусственном интеллекте и система обработки больших данных. А ООП используется в прикладном программировании и эта парадигма так популярна и так долго держит нишу, исключительно потому что всё в сфере прикладного ПО легко абстрагируется до классов и объектов, при этом код сохраняет логику естественного хода вещей.
Здесь вопрос не крутости парадигм, а сфер применения.
p.s. Вы путаете функциональное программирование со структурным
ООП ничего не усложняет. Просто предмет может быть сложным сам по себе.
Код же пишется не ради кода, а для бизнеса, у которого есть процессы, сущности какие-то.
Можно тебя чуть-чуть поправить, ООП это не о структурировании кода. Это о структурировании данных.
В этом и состоит главное отличие от остальных стилей (парадигм).
Поддержка кода хоть в 1000 хоть в 10000 строк - не сложно если весь код оперирует с 5-6 типами данных. А вот когда количество вариантов данных разрастается, функциональная парадигма начинает давать сбои.
Если брать твой пример с машиной, то ООП пытается описать все характеристики объекта И все действия которые можно с этим объектом произвести. Пока ты описываешь только машину (причем конкретный тип), то все ок, но потом ты захочешь описать этим же объектом к примеру трактор, и все, нужно полностью переделывать не только структуру данных, но все методы(функции для работы с ней). А когда количество вариантов разрастается, то кроме ООП вариантов то и не остаётся.
Может слегка сумбурно получилось, но надеюсь идею я смог донести.
А что насчёт ECS(Entity Component System) ?)
В примере про вампира и оружие нужен третий класс -- Damage или Hit, а оружие и вампир должны реализовывать интерфейсы IWeapon и IDamagable.
Но вообще поддержу автора, ооп чаще всего не нужно, особенно в не умелых руках
класс это как список но с именами для переменных?
ньетъ
это как структура, только с функциями и переменными
Такое чувство, будто собраны все "фишки" ООП в кучу, но максимально абстрактно друг от друга + намеренно переусложнил логику примеров. Тот же пример дамагом - зачем то намеренно запутываешь лишней логикой про то, что удар это не урон и прочей философией. У вампира делаем метод дамаг, в методе дамаг он использует оружие, класс которого ему передали при инициализации к примеру. У оружия есть атрибут - дамаг(инт), когда у вампира вызываем дамаг, в метод передаем каким оружием (если его у вампира несколько разных) и кого бьём. В теле метода две строчки
self.hp += weapon.damage
enemy.hp -= weapon.damage
И плов готов. И кстати все эти 4 атрибута изменяем через сеттеры (которые типа не нужны), в которых проводим необходимую логику валидации аргументов, перед тем как изменить состояние объектов.
ненадо запутывать людей софистикой всякой) я ожидал услышать реальные подводные камни ООП, а не такую абстракцию и философию. И какой подход к организации кода не растит массу кода при добавлении новых фич? Это какой-то нонсенс вообще
Я же сказал, пример сильно упрощен, обычно деталей гораздо больше
Классный видос!) Можешь сказать имя темы как у тебя для android studio
Material Darker
все его учат, о нем спрашиваю на собесах, но никто не использует. 80% кода это спагетти из функций и заправленные структурами.
Я опытный программист.
Забыл добавить «опытный программист 1с»)
Так то да, но это упирается в то что работодатель старается сделать разработку как можно дешевле и нанимает слабых разработчиков, которые умеют только в процедурку
6:43 только ситхи все возводят в абсолют
Автор путает процедурное программирование с функциональным
почему нельзя перенести метод урона в суперкласс, от которого будут наследоваться два (или более) объекта сабклассов (вампир и богатырь), и через код реюз пеиеписать его в сабклассе вампир таким образом, чтобы нанесенный урон плюсовался к хп объекта сабкласса?
Да не, на самом деле вариантов много, просто я говорил о том, что даже такая небольшая фишка как один класс будет реализована большим количеством кода и создаст кучу неявных связей
Тут ничего не поделаешь увы
А что если переименовать функцию дамаг в функцию удар то и создовать новый класс не надо и вампиризм можно там же написать
Привет Bebr0. У тебя хорошо получается снимать видео! Не сдавайся, и ты обязательно достигнешь огромных высот!
Смешно звучит: Привет, у тебя хорошо получается) Как будто школьника хвалят за пятерку
Я не хочу обидеть автора ,но он не поминает о чем снял видео.ООП - ЭТО ВЕРСТАК ДЛЯ СОЗДАНИЯ ИНСТРУМЕНТОВ!
В дальнейшем с помощью этих инструментов можно будет строить дома. Один дом,два дома ,три дома,и даже четыре.Если вам будет не хватать инструментов при строительстве дома,вы всегда можете сделать его у себя на верстаке,или переделать инструмент,дополнить или расширить его.А самое главное такой верстак вы можете таскать собой,и строить дома где угодно.Сразу скажу,если у вас в планах построить скворечник,или собачею будку,то вам не нужен верстак.А вот если вы пойдете работать в организацию где стоят на заказ скворечники собачьи будки ,то там в скорей всего пользуются верстаком .Я не буду приводить пример,мне лень,но если попросите,я потом добавлю пример такого верстака,всем удачи)
Спасибо за адекватную критику!
Видео о том, что для постройки домов не всегда можно использовать ООП, либо использовать ООП в комбинации
Чел, ты путаешь функциональное и процедурное программирование
Го видос про GUI в Spigot?
Уже есть такой у меня)
Класс вампир должен иметь метод "высасывание жизни", который связан с методом "удар", и получать информацию о количестве высасывания жизни на основе количества нанесённого урона методом "удар". Это же элементарно.
Зачем городить какую-то ересь?
Я буду почти олд.
Я хз как можно не юзать ООП. Это же . ну. ЭТО БАЗА. То что код всегда только растет, это наоборот хорошо, значит новый хорошо ложиться на старый, а значит код хороший. и изменять его легче. И новый код писать проще, не задумываясь о старом. И понимать объект пачкаМасла гораздо легче
я вообще не представляю программирование без oop
а на бусти есть твои откровенные фоточки? Я просто думаю. покупать или нет.
Для тебя сделаем))
А если серьёзно, то там скоро будет курс по джава и видосы раньше выходят
@@BeBr0 а ты какого телосложения?
@@y9maly Тебе понравится
@@BeBr0 🥰🥵🥺🥰🥵🥺🥵🥰🥺🥵🥺🥵🥺🥰🥺
Пробовал учить C++ он мне мозги взрывал своим ООП. Сейчас учу JS вот где идеальное ООП. Не нужно создавать дурацких классов. Просто сразу делаешь объект и нечего лишнего. Вообще не кому не рекомендую учить C++ напрочь желание программировать отбивает.
После с# хотел изучить жс, смотря на код в жс блевать охота 🤢
@@Shumtakatak учи поверх js еще ts, проблем не будет
@@Shumtakatak такая же ситуация была. Первые мысли: "еп--ь что это, что за объектно-прототипное программирование"
жс это уродство
за 20 лет так и не осилил
за гвозди спасибо
Ооп структурироваеть код.
Безусловно, то есть другие подходы, которые структурируют код лучше
Звук имба
Учите python там есть функциональное программирование.
Bebro после того как прочитал этот комментарий:
Смотрите мое прошлое видео!!!
Я: Смотрите мой комментарий под тем видео!!!
И это видео(про ООП) аргумент в пользу изучения Python в начале пути программиста.
Функциональное программирование есть везде
Если бы я хотел писать на функционалке, писал бы на котлине))
И какое же там фп есть? Обычные функции? Это все? Лямбда, которая ограничена одной строкой? Бред
Окей
Имз имба топер да абоба бебры
13 мин назад)
теперь сделай видео ФП говно!
Я уже думаю над роликом по ФП, ролик про ООП подводка к нему
@@BeBr0 ну ФП говно ещё то на самом деле) по этому у фпшников такие зарплаты космические, никто с хорошим психологическим состоянием не согласился бы ни за что с таким говном работать как фп
Я сразу подумал, что там 1,57миллиона, а это всего тысячи. Контент качественнее Хауди, а подписчиков так мало. Что за дела?
Не все сразу)
Спасибо, очень приятно :3
ООП Г*ВНО?! 💩
ЫЫЫЫ?