Принципы ООП, инкапсуляция, абстракция, наследование, полиморфизм, Unity, C#

[@user-huyuzeraaaaady]

хоть где-то узнала как работает стиральная машинка))))))))))

[@hello_nazarko]

Больше 10 лет опыта с юнити, множество пересмотренных видосов и имхо - у тебя самые исчерпывающие, толковые по повествованию \ примерам. Подписался, буду рекомендовать, жду новый контент!

[@bur-mq1mq]

Согласен, просмотрел некоторые видео, очень много понял, что не понимал из других! А у канала всего 2к подписчиков!

[@scc-6]

+, согласен

[@fuuuns]

Подписываюсь. И под комментаторами и на канал ))) 10 лет смотрел искал разное... Только это стрельнуло. Схоронил.

[@NikitaJe_]

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

[@doxo3469]

По качеству видео прямо ваау, все понятно и супер, люблю паузы между слов, так получается запомнить и обдумать услышанное)

[@sergeykazantsev1655]

Надеюсь, паузы не такие уж большие)

[@doxo3469]

нет, это отнюдь не стеб, мне реально так очень легко понимать информацию @@sergeykazantsev1655

[@youpubeqwer]

Супер, самое лучшее объяснение ООП что нашел! Продолжайте снимать уроки, у вас талант учить!

[@АндрейНиколаевич-г9р]

Класс, спасибо, чётко, с примером и понятно. Десяток видео пересмотрел, и все как из утюга пишут один и тот же код и говорят, вот это полиморфизм, а в чем его суть не понятно, ещё раз благодарю.

[@timelapse3606]

Ходят слухи, есть запустить стиралку в 4 утра с оборотами 666 в минуту, можно призвать Сергея) спасибо за видео, помог азы вспомнить

[@АнастасияМитюшина-ь7о]

Спасибо за видео, продолжайте в том же духе!!!! Хотелось бы в дальнейшем увидеть про ECS

[@zjcom-bb7ek]

Я В ШОКЕ. Столько роликов было просмотрено, а так разъяснить паблик от прайвета никто не смог!

[@younggd]

вы - настоящий герой. спасибо за ваши труды, безмерно вам благодарен.

[@flyman811]

Sergey Kazantsev, из вас хороший бы учитель информатики получился. Лукас и подписота)

[@ntn2866]

Это лучшие уроки которые я встречал на ютубе. Спасибо огромное! Всё просто и понятно. Лайк, подписка. 🔥🔥🔥🔥

[@Kancernik]

Здравствуйте! Ваш канал это настоящая находка, которую посоветовал мне друг. Данный канал единственный, на котором мне не скучно погрузиться в детали шаблонов проектирования и разобраться в некоторых моментах теории программирования! Очень жду новые видосы, старые уже пересмотрел по 3 раза)

[@sergeykazantsev1655]

Спасибо большое, у меня сейчас мало есть сил и времени на канал но все равно пытаюсь хоть часик хоть пол часика в день ему уделять)

[@shelikhann]

Не понимаю, почему так мало просмотров, очень недооцененный контент, еще не находил настолько исчерпывающих объяснений на эту тему, наконец-то я понял как это работает

[@scc-6]

Класс не конвертируется, а одновременно является и тем и другим(про наследование) Классно сказано. До этого я обкастил в голове, а так достаточно спросить, чем является

[@apofex]

Только погружаюсь в разработку игр и ваши видео просто находка! Спасибо.

[@void4365]

Единственный видос по ооп, который я действительно слушал

[@sunsungie]

это просто обалденно, огромная благодарность за это видео, всё супер понятно

[@ephemerayne]

Приятно слушать автора и все хорошо объясняет! Спасибо)

[@wholesomecrimson]

очень информативное и понятное видео, а еще вставки невероятно смешные

[@Greshnoff]

Спасибо, всё очень хорошо объяснено. У вас талант учителя!

[@Djegur]

Спасибо ОГРОМНОЕ. Очень понятно и круто объяснили!!! Это лучший канал по Юнити на русскоязычном ютубе. Спасибо.

[@ВладиславХрущев-ч2й]

Сергей, спасибо! У Вас лучшая подача материала) Буду ждать новые видосы!

[@Дарья-м1ф9т]

Гениальное оформление материала🍑

[@ДмитрийБарсуков-ъ8р]

Спасибо, все очень доступно. Вроде как все знал, но послушал и стал знать еще лучше :)))

[@Creeper71]

Желаю развития каналу! Очень хорошие объяснения. Наконец понял всю идею инкапсуляции

[@СержПахомов-л4я]

Спасибо большое за ваш труд. Как всегда на высоте. Хотелось бы что нибудь про чистую архитектуру, с простейшем примером реализации ,например ToDo List. А то концепций и идей много но не всегда понятно можно ли её добиться на практике

[@sergeykazantsev1655]

Спасибо! У меня есть рубрика паттерны на практике, где я делаю небольшие но полноценные игры Подробного разбора именно архитектуры там нет, но можете посмотреть на гитхабе проекты, две игры уже сделано

[@adrassad]

Видео огонь, очень доходчиво и примеры отличные !🤘

[@botcser]

Кстати говоря, говорят, что лучше создавать контроллер для управлением состояний игрока, а не пихать логику в самого игрока, аля MVC, но для наглядности этот пример то что надо👍

[@sergeykazantsev1655]

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

[@august4228]

Спасибо за работу! Многое помогло понять.

[@wepko]

Супер, ты золотой мужик

[@Miketo_Sanso]

Бро, лучший)) Сейчас задумываюсь о том, чтобы работу найти, твои ролики для повторения материала и изучения нового - просто спасение :D. Респект, лайк и подписка. Даешь полезный контент!

[@КорвинКори-б6у]

Мы скучаем по лучшим обучающим видосам 😊

[@sergeykazantsev1655]

Июль и август выдались для меня очень непростыми) И на работе тяжело, и вообще в другую страну переезжаю. Потихоньку пилю материал по новой игре) Но когда я её опубликую - не знаю. Очень непростая игра получается)

[@КорвинКори-б6у]

@@sergeykazantsev1655 Поздравляю с переездом!!! Если не секрет, в какую страну? Сам мечтаю переехать, но что-то не находится работка с релокейтом.

[@sergeykazantsev1655]

Спасибо! В Германию, в город Гамбург. Работку с релокейтом действительно нелегко найти, много фирм которые зовут тебя на фул удалёнку и им всеравно в какой ты стране, а вот с релоком предложений мало и релокают в основном синьоров. Я искал около года

[@Black_Raven-]

дуже корисні відоси. Отримую максимальний апгрейді скіллсів від цього. Продовжуй - це в кайф

[@Kancernik]

Посмотрел, хоть все принципы и знаю =) Классный канал!

[@timurcraft2018]

Спасибо, кажется, я начал что-то понимать про ООП 😅

[@nerpa3056]

Очень подробно и понятно, спасибо!

[@botcser]

Пизец, не знал, что инженеры стиралок владеют навыком ООП!

[@askardw636]

Очень круто, продолжайте!

[@kkolyann2]

Отличное видео, для начинающих самое то)

[@scc-6]

Не много не понимаю, чем имено мне нравятся твои видосы. Наверное, у тебя голос классный

[@scc-6]

Еще практика всегда есть, понятно, нахуя

[@sergeykazantsev1655]

Спасибо. Когда-нибудь я куплю хороший микрофон и перестану записывать в пустых комнатах - тогда вообще будет АСМР

[@Desotterro]

Спасибо тебе, мил человек!

[@Дневниксамоучки-ъ1и]

Посмотрев видео и примеры из геймдева самому аж захотелось перейти в геймдев из бэкенда 🤣🤣

[@sergeykazantsev1655]

А мне в последнее время наоборот, хочется освоить что-то еще, например бэкенд

[@vladimirkraft4315]

Спасибо большое за урок!

[@lopiktest5193]

Благодарю за видео, синьер

[@EliseyUnity]

Спасибо большое, сразу видно настоящий Сеньер. Сергей, подскажите пожалуйста какие курсы вы осваивали для c# и Unity, где вы так хорошо выучились. И можете посоветовать достоверные источники пожалуйста, желательно русскоязычные!?

[@sergeykazantsev1655]

На днях сделаю подборку и выложу ее как пост от сообщества, наверное)

[@Djegur]

@@sergeykazantsev1655 ждем

[@КорвинКори-б6у]

Лучший, спасибо за годноту

[@XjsjvsJfkekxg]

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

[@sergeykazantsev1655]

MVVM, Декоратор, Фабрики, всякие DI-контейнеры, например

[@Digildon]

пасиба, польза есть

[@obusis]

🤌 идеально

[@14dayspon]

Сказка на ночь

[@АнтонЕлумеев]

Спасибо за видео!

[@PinkPanteRus]

Спасибо!

[@sashko-w8f]

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

[@sergeykazantsev1655]

Они взаимосвязаны и вместе используются для решения одной и той же задачи. Отсюда и похожесть. Можно сказать что это три части одного целого Но всё же их хорошо бы различать)

[@USSR-Lenin-Stalin-Forever]

22:15 Не понял зачем делать getPrice абстрактным (дублирование кода все равно осталось), там же для юнита можно просто поля создать стоимость и стоимость по модулю и гетпрайс просто выбирает нужное поле. Да и магические числа это плохо само по себе

[@sergeykazantsev1655]

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

[@maxbystryk7266]

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

[@pashafilenko1567]

Отличное видео!

[@KeysREC]

Как это всё работает то понятно, а вот как это всё писать не понятно :D

[@sergeykazantsev1655]

у меня на канале есть плейлист "Паттерны на практике". В рамках неё я запилил игрульку, вертикальный скроллер, вылил в открытую проект на гитхаб. Связку - полиморфизм + наследование + абстракция можно посмотреть там на логике Interactables - как я описал астероиды, аптечки, монетки, щиты и тд)

[@sergeykazantsev1655]

а так, просто надо пытаться потихоньку писать, косячить, понимать где накосячил, переписывать и так по кругу) с каждым следующим кругом будет чуть яснее)

[@KeysREC]

@@sergeykazantsev1655 о спасибо, надо будет глянуть

[@АбдуллахАхфасаев]

Скажите пожалуйста, а upcast используется исключительно в массивах? если где хоть как то объясняют про суть upcasting'а говорят про масивы, не уж то нет других примеров

[@sergeykazantsev1655]

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

[@hackzem07]

Привет, в конце видео ты показал код, где для каждого типа юнита ты создал свою переменную, а если у нас 10 типов, ошибочка в конце.😅

[@sergeykazantsev1655]

Можно, пожалуйста по конкретней, в чём ты считаешь тут ошибочку? Желательно с таймингом, а то я пока не понимаю о какой переменной на каждого юнита идёт речь

[@ИванРодионов-е4е]

По сути же мы все равно можем менять переменную health из другого класса через метод AddHealth, задать например значение в миллион или я что-то не понял?

[@sergeykazantsev1655]

менять переменную через метод лучше, чем менять переменную напрямую. в метод легко добавить валидацию(ту же проверку на миллион) и метод проще дебажить и логгировать, нежели изменение поля напрямую

[@ИванРодионов-е4е]

@@sergeykazantsev1655 спасибо за ответ!

[@DarkIllusoire]

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

[@sergeykazantsev1655]

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

[@sergeykazantsev1655]

Цитата от Рихтера(CLR via C#) Инкапсуляция данных означает, что поля типа ни в коем случае не следует открывать для общего доступа, так как в этом случае слишком просто написать код, способный испортить сведения о состоянии объекта путем ненадлежащего применения полей. Цитата от Шилдта(Java руководство чего-то там) Инкапсуляция - это механизм, который связывает код вместе с обрабатываемыми данными и сохраняет их в безопасности как от внешнего влияния так и от ошибочного пользования Не могу я вышеназванных дядь назвать какими-то мутными личностями которые ввели дурацкую традицию и ввели всех в заблуждение. Ну разве что если с вашей стороны есть более авторитетные личности которые доказывают что эти авторы заблуждаются и неправы)

[@DarkIllusoire]

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

[@sergeykazantsev1655]

Как по мне к людям которые больше 20ти лет пишут код, и по своему опыту написали книги и постоянно продолжают их издавать в новых редакциях, к книгам которых с большим уважением и респектом относятся лиды и архитекторы с зп 300к в наносекунду - к этим людям по крайней мере стоит прислушаться. Авось за такое время они что-то поняли. И это я уже не говорю про свой личный опыт, который уже за 7 лет перевалил. Ну а так мы на второй круг заходим - я считаю что сокрытие это не пятое колесо - а полное продолжение идеи изоляции кода от случайного воздействия со стороны. Насчёт того что инкапсуляция происходит и без сокрытия данных - я не понимаю суть этого утверждения. Это как утверждать что "Раз на велосипеде можно ездить без седушки(и я уверен такие бывают) давайте доказывать всем что велосипед это транспортное средство с рулем двумя колёсами но без седла - ибо седушка не обязательна"

[@DarkIllusoire]

@@sergeykazantsev1655 ещё раз, инкапсуляция - это буквально упаковка переменных и функций в объект, все. Сокрытие в этом всем никак не помогает и не мешает, то есть в определении оно лишнее. И ещё раз, медленно, на пальцах инкапсуляция случается без использования сокрытия и есть ООП языки, в которых НЕТ области видимости в принципе, то есть совсем нет, вот вообще)) И вы можете хоть Иисуса Христа поставить в качестве авторитета, привести миллион доводов, что сокрытие очень важная штука(с чем я и не спорю), но факты, упрямая штука - инкапсуляция вполне себе существует без сокрытия, хоть обшилдься и обрехтерись в десна

[@ggplay7778]

Спасибо, помогло

[@naumov-channel]

А будут еще видое?

[@sergeykazantsev1655]

Будут, но нескоро и нечасто, в последнем сообщества объяснял почему)

[@vladoosick806]

Здравствуйте, скажите, пожалуйста, почему в примере для проверки, является ли юнит кратным 3, не используется вот такая формула: return (_id % 3 == 0)? То есть если сейчас юнит является 3 по счёту то номер перекрасится в жёлтый? а так по формуле как у вас 2 юнит должен перекраситься в желтый цвет. Объясните, пожалуйста, почему именно такая формула используется.

[@sergeykazantsev1655]

Здравствуйте, индекс начинается с нуля, поэтому к id мы прибавляем единицу и только потом делим на 3

[@vladoosick806]

@sergeykazantsev1655 а, теперь понял. Спасибо большое!

[@hactle_d]

Как же меня убивают эти всплывающие картинки, особенно при большом определении

[@ГеннадийШушпанов-д1ч]

Я бы все же не сопоставлял наследование с копированием, пусть даже и умным. Ведь ниже Вы нашли другое сопоставление, отметив, что производный класс является и классом-предком. А раз он является, то и имеет все, что предку положено, без всякого копирования.

[@sergeykazantsev1655]

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

[@ГеннадийШушпанов-д1ч]

@@sergeykazantsev1655 возможность избежать копирования при наследовании, скорее побочный эффект. Процедурный подход тоже в плюсы записывал эту возможность. Наследование определяет отношение между абстрактным и детальным. При наследовании потомок является предком. А вот если потомок расширяет предка, то это другое отношение -- расширение. При нем потомок не является предком. Например, прямоугольник является фигурой -- это наследование, а трехмерная точка расширяет двумерную, но не является ей. То, что оба отношения реализованы одинаково лишь случайность. А книги пишут люди со своих точек зрения. С ними можно и поспорить. Не так ли? Мы ведь тоже спорим, несмотря на то, что мнение другого -- написанный текст, маленькая книга.

[@sergeykazantsev1655]

Я ваш аргумент про точки зрения понимаю, Но я считаю что если человек на каком-то деле съел собаку, а всякие Кнуты, Рихтеры, Фаулеры и прочие авторы которые переиздают одну и ту же книгу в течение 20 лет, редактируют, улучшают ее, дискутируют на форумах и тд - это не просто вкусовое мнение - это занесенный на бумагу многолетний опыт, как минимум выслушать стоит. А так если спорить - надо тогда на факты выводить) Почему избегание копирования побочный эффект? Почему именно абстрагирование и возможность отделение абстракции от деталей важнее? А если главное в наследовании это отношение между абстрактным и детальным - то зачем тогда принцип Абстракция - разве они не одно и то же тогда объясняют? Все равно конечно на вкусовщину и личный опыт сойдемся - но мало ли

[@ГеннадийШушпанов-д1ч]

@@sergeykazantsev1655 книги конечно читать надо :). Да, это материализованный опыт. Но всего лишь опыт. И если выводы противоречат вашему опыту, то почему бы не поспорить? Да, в наследовании отношение абстрактный-детальный важнее копирования. Потому что это фундамент ООП, причина для наследования, база для полиморфизма. А то, что на этом можно строки кода экономить -- это побочный эффект. Однако зримый эффект, вот на нём и фокусируются. Вы себе вопрос задайте, как часто причиной наследования была необходимость избежать копирования? Или все же чаще Вы иерархию абстракций строили. Судя по википедии принцип абстракции вообще к наследованию не относится. Он призывает избегать дублирования кода "путем использования абстракций, предоставляемых языком программирования или библиотеками программного обеспечения". Так что абстракции в принципе абстракции, это несколько иное понятие, нежели абстракции в наследовании ООП. Примечание. Я в этом топике только Ваши комментарии вижу почему-то.

[@sergeykazantsev1655]

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

[@Алексей-ц1г9е]

Пример со стиральной машинкой отличный способ показать процедурное программирование: 1 загрузить_тряпки(); 2 выбрать_режим(стирать_тряпки); 3 засыпать_порошок(); 4 начать_стирку(); А причем сдесь ООП ? И вообще, кто вам мешает скрывать переменные и методы в процедурном программировании ? Что вы до них так докапываетесь. Половина ютуб "учителей" сами не особо понимают что такое ООП, и морочат голову новичкам.

[@sergeykazantsev1655]

Ох уж эти "эксперты в комментах" - которые притягивают тему которая вообще в ролике не затрагивается и в итоге эти эксперты спорят сами с собой Ну давайте по фактам... Причем тут процедурное программирование и ваш пример когда речь идёт об ООП? В моём примере - стиральная машинка - объект, есть внутренние данные и методы, которые непосредственно с ней взаимодействуют, есть сокрытие некоторых данных от внешнего воздействия. В этом заключается инкапсуляция. Если не согласны, дайте конкретику и уточните. В процедурном программировании нет модификаторов public private и protected, в процедурном программировании нет понятия объект, зачем вообще в видео про ООП это накидывать?

[@Алексей-ц1г9е]

@@sergeykazantsev1655 В моем примере у стиральной машины тоже есть внутренние данные и методы, которые непосредственно с ней взаимодействуют, есть сокрытие некоторых данных от внешнего воздействия. Только это все набор функций в процедурном программировании. А если я эти функции и преременные залеплю одной структурой, будет это объектом ? Следует пояснить, чем нобор функций отличается от в объекта, ну или признать что пример с машинкой неудачный. Если из языка выкинуть указатели на память, то неважно ООП это или процедурный язык, намутить public private и protected не составит труда. Я пытаюсь понять что такое ООП, но вижу только процедурщиков, которые сами не понимают что они процедурщики. Ну или ООП нафиг никому не нужно, просто современный тренд для резюме.

[@sergeykazantsev1655]

Мое мнение, что главное различие между ООП и процедурным программированием заключается не столько в инкапсуляции, хотя и в ней тоже(ибо есть protected) но в самой идее абстракции, наследования и полиморфизма. Насколько я знаю, умного копирования структур с их возможностями расширения в процедурных языках нет. В конце видео я как раз привожу задачу на подсчёт суммы разных юнитов, и как раз таки показываю разницу как бы это решение приблизительно выглядело в процедурном коде и как это благодаря ООП можно завернуть и избежать дублирования логики Ну и также принцип DIP как раз говорит что благодаря такому подходу у нас инвертируется зависимость и подход разработки идёт не от частного к общему, а от общего к частному

[@Алексей-ц1г9е]

@@sergeykazantsev1655 Как я понял (в разных умных книжках написано по-разному) отличие ООП от процедур не в коде, а в подходе к решению. Объект должын быть самостоятельным, его не надо водить за ручку и говорить что ему делать, в противном случае и получаются процедуры завернутые в псевдо-классы. я как процедурщик запилил бы задачу с юнитами так (примерно): #define WAR 0 #define MAG 1 #define ARC 2 // WAR MAG ARC int unit_price_us[] = { 10, 20, 30 } int unit_price_ex[] = { 15, 40, 10 } int get_price(id, type) { if (type > 2) return 0; if (id % 3) return unit_price_us[type]; else return unit_price_ex[type]; } int get_sum() { int result =0; for (int id = 0; id < COUNT; id++) result += get_price(id, units[id]); return result; } Благодаря процедурам можно завернуть и избежать дублирования логики, избежать накопипастинье классов, сократить код и поднять производительность :)

[@sergeykazantsev1655]

Согласен, на процедурном тоже это не невыполнимая задача, вот только я не уверен что если задачка будет посложнее подсчёта суммы - могут начаться более наглядные сложности Например если ГД-шники захотят устроить АБ-тесты и потестить разные механики нанесения урона. Например: 1. Чистый и постоянный урон(всегда бьёт 3) 2. Ранжированный урон(2-5) 3. Чистый и постоянный но с вероятностью крита. В ООП ты создаёшь 3 класса, наследников одного базового с абстрактным методом CalculateDamage и можешь легко это всё переключать. В процедурном тоже можно так сделать, но я не уверен что это будет достаточно удобно.