0: Пытаешься разобраться с оуп, но постоянно путаешься. Кажется, слишком сложно, но это видео решит все твои проблемы. Сейчас я с великолепными анимациями и крайне простыми словами расскажу про оуп, так что ты будешь великолепно понимать, как использовать.

1: Каждый его принцип привет, меня влад зовут. Я работаю программистом на бэкенде уже 8 лет, а прямо сейчас в 1 из лучших компаний в мире и живу в Амстердаме на своём канале рассказываю о том, как тебе стать супер мощным программистом. Ооп. Это объектно?

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

3: Физический объект, а ещё 1 объект. Автомобиль позволяет нам быстрее передвигаться. Эти вещи кажутся нам привычными и понятными. Но вы задумывались, как вообще люди создают все эти объекты. Представим Илона маска, который собирается сделать свою 1 теслу.

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

5: Будущую машину, но ещё он прописал там различные функции, которые будут в неё встроены буквально действия, которые с ней можно будет выполнить. Кроме очевидного. Может быстро ехать. Он добавил функцию отслеживания знаков, включение кондиционер.

6: Круиз, контроль и другие и теперь, глядя на чертёж, можно понять, какую именно машину нужно произвести на заводе, так что elon musk пошёл туда и дал местным работягам свою схему, а они наштамповали ему миллионы тесл буквально физических объектов, которые.

7: Созданы на основе этого чертежа, и все они обладают теми свойствами и могут выполнять те действия, что были описаны на бумаге. Именно эта идея и лежит в основе ооп. В свои программы мы добавляем так называемые классы. Это просто текстовые

8: Файлы, где на специальном языке программирования, понятном компьютеру, мы пишем, что хотим создать на этом компе, как илон маск в своём чертеже. Если мы хотим создать компьютерную теслу, то нужно написать, какие у неё есть атрибуты, то есть показать

9: Будущей машины в нашей программе те самые максимальную скорость, текущее местоположение и расход энергии из вот этого чертежа. Такие атрибуты в ооп называются полями класса. Но ещё стоит добавить и функции, которые будут у нашей виртуальной тачки. Это буквально

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

11: Это то, что позволяет вам наконец понять сложные технические темы, но создание видео такого уровня сложный процесс. Я готовлю каждое неделями вместе с целой командой. Только благодаря вашей поддержке у нас появляются ресурсы, чтобы эту команду растить, а значит,

12: Делать больше таких роликов. Так что поставьте, пожалуйста, лайк этому видео и подпишитесь на канал, чтобы получить ещё больше такого контента как можно скорее. Например, пишем функцию быстрой езды в нашем классе. Можем назвать её драйв, ехать.

13: А параметрами туда передавать координаты, указывающие на место, куда именно едем. Соответственно, такая функция сохраняет переданные значения в поля местоположения самой машины, которые мы описали выше. И получается, что тесла как бы переме

14: Я в пространстве, когда выполняется функция езды. Тем не менее никто пока никуда не едет этот класс. То есть текстовый файл это просто чертёж, в котором мы написали, какие показатели есть у любой теслы в нашей программе, а также

15: Что эти теслы смогут в программе вообще делать? Теперь из него нам нужно создать объекты, которые уже смогут ездить. То есть нам нужен завод, куда мы передадим наш чертёж, а он нам создаст фактические теслы на его основе в разных языках программирования.

16: Это делается по разному в java, например, есть специальное слово нью, которое создаёт объект класса, чьё имя пишется сразу за этим словом хочу создать 5 тесл, пишу нью тесла 5 раз. В этом и заключается суть ооп мы единожды.

17: Создаём класс чертёж, где прописываем все параметры, что будут у наших объектов, а также какие функции они смогут выполнять. Затем на основе чертежа мы можем создать хоть 1000000 компьютерных объектов, которые там описали. И именно параметры этих объектов уже можно

18: Изменять, передавая им новые значения, а также запускать их функции, которыми те оснащены. Согласно чертежу. Например, по 1 чертежу. Мы можем создать 2 совершенно одинаковые теслы. Оба объекта имеют атрибут заряда аккумулятора, как написано в чертеже, но

19: Реальное значение этого атрибута в конкретной машине может быть разным в разное время, прямо как в реальном мире. Тоже самое с их функциями по классу чертежу любая тесла может ехать в какую-то точку. 1 можно отправить по 1 координатам, a2 по другим они обе поедут.

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

21: Мира с нужными атрибутами, из которого мы сможем создать фактический объект компьютерной карты. Также можно добавить класс города, у которого есть координаты местоположения на карте его поля, атрибуты. Но ведь тогда и карта должна знать про города.

22: Так ведь, значит, добавим новое поле и в класс карты массив городов, что на ней есть. В результате теперь можно создать несколько объектов виртуальных городов с разными координатами, затем создать объект виртуальной карты с набором этих городов, а далее.

23: Ещё и несколько объектов машин. Соответственно, любой машине. Теперь можно передать координаты нужного объекта города параметром функцию езды, и она поедет по карте именно в город с такими координатами. Звучит логично, так ведь в этом

24: И есть прелесть объектно ориентированного программирования. Все эти объекты мы создаём не по настоящему, а внутри компьютера. Это просто кусочки информации на нём. Но мы видим, как их взаимодействие между собой похоже на то, что нас окружает в реальном мире, а значит, программирование.

25: Становится сильно проще, поскольку нам легче понимать, как эти объекты связаны, но классы и объекты это только начало. Уже сейчас мы разберёмся с принципами ооп типа полиморфизма и инкапсуляции на супер простых примерах. Наконец то все станет понятно.

26: И вы сможете просто взять и сразу начать писать свои приложения. Но бывало же такое, что слушаешь, все понятно, начинаешь делать сразу проблемы. Это потому, что с каждой темой, что мы обсуждаем, нужно практиковаться. Для этого я сделал полностью бесплатный курс.

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

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

29: Гоночки и там и там нужны объекты машин, но неужели одни и те же? Здесь оп становится ещё мощнее, разрабатывая гоночки, какие поля мы бы добавили в класс. Чертёж для всех машин в игре нам важны максимальная скорость, разгон, дрифт, цвет.

30: И tuning все то, что определяет крутость и вероятность победы. Но если мы делаем приложение навигатор, то как бы выглядел класс для машин там здесь нам уже пофиг на цвет и тюнинг на drift и разгон в общем то тоже в контексте навигации на карте эти

31: Параметры машины не являются важными, поэтому мы пишем только те, что необходимы для навигации. Положение на карте и скорость поможет определить время до пункта назначения. Этих 2 полей уже достаточно, чтобы такой класс имел смысл в таком приложении и в этом

32: Заключается 1 принцип ооп абстракция. Не поняли. Смотрим дальше. Сейчас все подробно объясню. Если мы посмотрим на реальную машину, то сколько у неё, блин, параметров дофига, начиная от объёма двигателя, заканчивая объёмом бака с топливом и

33: Аэродинамика что за резины, сколько Мешков картошки можно запихать в багажник, каких показателей только нет, но когда мы пишем свою компьютерную игру, гоночки, то нам ведь пофиг на объём бака и в принципе на топливо, например, в игре бенз бесконечный пофиг и на объём двигателя.

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

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

36: Множество реальных деталей. Итог, абстракция на лошадь в приложении навигаторе. Мы абстрагируемся от сложности машины. Ещё дальше вообще оставляем в классе всего пару важных для нас параметров. И в этом сила принципа абстракции в каждой программе мы описываем

37: Только то, что реально нужно для конкретной задачи этого приложения. Именно вы, как разработчик той или иной программы, должны размышлять, какие параметры каждого из объектов в вашем коде действительно важны, а что можно отбросить, как видите, в зависимости от

38: Контекста приложений. Иногда нужно 1, иногда другое. Таким образом, для каждой программы вы создаёте разные классы чертежей, в которых пишите только те поля, которые важны именно в этой программе. Тоже самое с функциями. У реальных машин много разных

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

40: Его внутренние составляющие, чтобы мы ничего не сломали. Невзначай он соблюдал принцип инкапсуляции, который действует и в ооп. Что это такое? Ваш смартфон это сложное устройство, в котором дофига хитрой электроники и разных

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

42: Гораздо надёжнее, ведь если бы все провода и микросхемы были на виду, то я бы полез туда своими клешнями посмотреть, а что там как устроено ну и сломал бы, конечно, причём тут код сейчас объясню, представим, что мы программисты в apple и пишем.

43: Приложение камера для айфона. Создадим класс и добавим туда пару полей, количество свободной памяти и список фоток. А ещё добавим ему функцию тейк фото сделать фото как она будет работать для простоты примера. Пусть сначала проверяет, что на айфоне

44: Есть достаточно свободного места, а затем добавляет новый объект фото в список всех фоток айфона, ну и конечно отнимает 10 мегабайт от количества свободного места, раз уж новая фотка появилась из класса, создадим объект камеры и он будет выполнять свои функции в нашем айфоне кру.

45: Очень даже, но тут есть 1 маленькая деталь, которую мы не учли. Все покупают наши айфоны и фоткают все подряд через наше приложение камеры. Это великолепно, но вдруг становится популярен тиндер приложение для знакомств. Люди ставят его себе, а в нём можно добавлять

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

47: Нашего ведома может выгрузиться весь наш фотоальбом, и это недопустимо, ведь там могут оказаться фотки с женой на Дне рождения. Тёщи. Вряд ли они привлекут потенциальную пару. Тот факт, что список всех фото доступен любому желающему создаёт возможность для вот так.

48: Каких проблем? Класс камеры никак не контролирует, кто и как использует его поля. Если какой-то другой объект захочет получить к ним доступ, это легко. А если использует эти фото неверно, наш класс не может этому помешать. В своих программах мы никогда

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

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

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

52: Тиндер попробует обратиться к Такому полю нашего объекта напрямую то код просто не скомпилится, а значит, использовать это поле неправильно, больше не получится. Для правильного же доступа мы сделаем в нашем классе дополнительную функцию.

53: Get photos получить фотки. В ней мы напишем код, который спросит разрешение у владельца о доступе к конкретным фотокарточкам, а не всем, и уже потом выдаст их таким образом, любые другие объекты смогут вызывать эту функцию, чтобы

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

55: Надёжно защищено. Мы как будто поместили его внутренние детали в тот самый изящный корпус, а снаружи оставили лишь простые и удобные функции, которые делают все правильно. Это и есть инкапсуляция, но как создают настоящие приложения уже

56: Пишешь какие-то программки, но они далеки от реальных, как в них получать информацию по интернету, а как хранить это все в базе данных, что за модные микросервисы и кафка научиться с этим работать можно на моём java буткемпе, это интенсивная учебная

57: Программа, где ты как будто стажируешься в it компании, попадаешь в команду других программистов под руководством опытного ментора, реального разработчика из Сбера или яндекса в 1 команде вы вместе пишите огромную социальную сеть из 9 микросервисов.

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

59: Плюс вы созваниваетесь несколько раз в неделю, чтобы задавать любые вопросы, а в чате поддержки можно получить помощь ментора вообще в любое время, в итоге ты, по сути получаешь опыт работы в it проект под высокие нагрузки команда опытный разработчик, ментер современный.

60: Настоящие процессы scrum кодревью ретроспективы все как в реальной it компании регистрируйся на java буткемп по ссылке в описании и уже совсем скоро старт нового потока вы задумывались, почему персонажи world of warcraft.

61: Так похожи, но в то же время обладают своими уникальными способностями. Все благодаря ещё 1 важному принципу оууп. В мире wow есть множество рас люди, эльфы, гномы, зомби, гоблины и даже огромные коровы, таурены вы можете

62: Играть за любого из них, бегать по крутым локациям, выполнять квесты и, конечно, бить врагов, как разработчики wow добились того, что совсем разные персонажи могут вести себя одинаково, и goblins, и zombie имеют показатель здоровья, какую-то пушку в руках, а также текущую.

63: Уровень наивно предполагать, что в коде игры для них обоих существует по классу чертежу, где написано, что и тот и другой обладают всем вышеописанным почему? Потому что взгляните, сколько дублирования было бы в таких классах. Имя здоровье мана уровен.

64: Оружие куча всего ещё различные функции этих персонажей ходить, драться, говорить, брать задания, смотреть карту, открывать инвентарь и прочее все нужно писать по 2 раза, хотя почему по 2, есть же и другие персонажи, у которых тоже должны быть свои классы, в которых что pizza.

65: Тоже самое. А если таких классов будет 100, может же в игре быть 100 разных персонажей? В таком коде было бы невероятно сложно ориентироваться. Поэтому программисты подумали, блин, а что, если сделать отдельный класс, в котором будет содержаться все общее?

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

67: Но неясно, какой именно описано, очень схематично, но теперь можно, глядя на этот базовый класс, создать ещё 1 конкретный, например, для гоблина, и сказать, что пусть он наследуется от основного, что это значит, когда мы наследуем 1 класс от

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

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

70: Мы это сделали. Теперь у нас, по сути, 2 одинаковых класса, только в 1 из них все поля и функции невидимы. А толку, что резонное замечание дело в том, что теперь мы можем в классе наследники добавлять ещё и новые поля и функции, которые уникальны именно

71: Для него в придачу к тем, что унаследованы от базового. Например, гоблин получает особый навык хитрости, который доступен только ему. Это ведь очень удобно, чтобы создать нового персонажа, мы просто взяли некоторую основу для них всех и добавили туда-то, что делает на

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

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

74: Следование. Теперь нам нужно лишь добавить уникальный навык для зомби. И все. И мы можем создать хоть 100 персонажей. Супер. Легко нам достаточно сделать для каждого класс, унаследовать от базового и добавить каждому уникальный навык, а не весь код, как раньше. В этом и состоит суть.

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

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

77: И его нужно знать просто великолепно. Ворлд оф варкрафт есть куча разных зелий, и у каждого свой особый эффект, хотя они и выглядят идентично. Ещё 1 принцип оуп позволяет использовать их одинаково, но получать уникальный результат.

78: Так, представим, что мы разрабатываем свою систему зелий в нашей игре. Разумеется, у нас был бы базовый класс, в котором хранились бы поля, общие для всех зелий размер и цена. А ещё их можно пить. Так что добавим функцию дринк. Она будет принимать параметр.

79: Персонажа, который пьёт это зелье. А дальше можем создать конкретные классы зелий, например, зелье здоровья. Наследуем его от базового класса и получаем копии всех полей и функций. Но тут важная деталь, функция дринк, которая

80: Мы унаследовали пустая, ведь мы не могли ничего в ней написать для базового класса, так как у базового зелья нет никакого эффекта, а вот у конкретного эффект быть должен. В этом и смысл. Поэтому в классе зелья здоровья мы можем снова написать эту функцию.

81: Дринг, но уже добавить туда код. Такое зелье увеличивает здоровье переданного персонажа на 10. То, что мы сделали, называется переопределением функции. Это ситуация, когда 1 класс наследуется от другого, но его не устраивает то

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

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

84: Просто наследовать пустую функцию, значит и в нём переопределяем. Пусть увеличит ману переданного персонажа на 10. И вот благодаря наследованию мы снова можем легко создавать целую кучу зелий, а когда у каждого есть переопределённая функция, то все они работают по

85: Разному и дают уникальные эффекты. Создал объект зелья, здоровья пьёшь, а оно здоровье восстанавливает. Пьёшь зелье маны. В нём работает функция по восстановлению маны. Удобно, но вы мне скажете, а Нафига вообще тогда эта функция в базовом классе? Она тупо пуста.

86: Мы её всегда переопределяем в конкретных зельях, так можете её выпилить, и пусть у каждого класса зелья будет своя собственная функция, а не наследуемая. Но на самом деле эта пустая функция в базовом классе позволяет делать 1 невероятно важную и удобную вещь. Смотрите, вни.

87: Внимательно. Насколько гибкими могут быть ваши программы с её помощью, пусть у персонажа игры есть набор зелей, который нужно выпить перед битвой в программе. Это был бы массив, в котором хранятся зелья, объекты. И посмотрите, это просто массив базового

88: Класса, а не конкретных классов Наследников. Благодаря этому в таком массиве могут содержаться любые объекты зелья. Ведь все они наследуются от 1 базового класса. Массив без проблем их примет, так как все они зелья. Таким образом, наследование позволяет нам

89: Писать код общий для всех классов, которые наследуются от 1 родительского, но это ещё не все, что если теперь наш персонаж хочет выпить все зелья из набора, для этого можно запустить цикл по массиву зелий и у каждого вызывать функцию дринг, передавая

90: В неё объект персонажа. И вот тут мы подходим к самому главному. Как думаете, какой код выполнится, когда будем пить 1 зелье? Ведь эта функция пуста в классе зелий, с которыми мы вроде тут работаем, и кажется, что ничего не должно произойти, но она

91: На самом деле, во время выполнения ваша программа всегда знает, с какими конкретными объектами она работает. Когда цикл возьмёт 1 зелье из списка, то в переменной будет храниться именно этот объект конкретно зелье здоровья. И если вызвать у него

92: Функцию дринк, то, что произойдёт буквально то, что мы написали в ней в классе зелья здоровья. Персонажу прибавится 10 очков здоровья. Затем цикл возьмёт 2 зелье из массива и снова во время выполнения ваша программа будет знать конкретно, что это за объект. Это

93: Зелье маны, пьём его выполняется тот код, который написан для этой функции в классе зелья, маны и так далее. Для всех зелей в списке у каждого из них своя особенная функция дринг, которая работает по разному, и наша программа способна понимать, какую

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

95: Можно писать код, который эту функцию вызывает, и быть уверенным, что у любого класса наследника она точно есть, потому что она ведь буквально копируется в них из базового, но вот только классы наследники могут её переопределить и написать, как она будет работать.

96: Конкретно в их случае, но тот факт, что она гарантированно есть у них всех позволяет нам писать абстрактный код, которому неважно, работает он с зельем здоровья или маны, он работает просто вообще с любым зельем. В нашей программе можно создать ещё 10 других.

97: Унаследовать от базового класса и этот массив и цикл, они будут работать с новыми объектами. Тоже их не придётся менять, потому что у них всех гарантированно есть функция дринк. Тем не менее, во время выполнения наша программа будет вызывать именно функцию

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

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

100: Обращаться с объектами 1 базового класса, понимая при том их конкретный класс во время выполнения для вызова именно их функций и называется полиморфизмом. Это последний и самый мощный принцип ооп, если были

101: Морфизма не было. То, как бы мы пили 3 разных зелья в нашей игре, создали бы объект зелья, здоровья, выпили бы его, потом бы создали зелье маны, пьём, потом зелье, силы тоже выпили и так далее. Когда у вас в игре 3 зелья, это не очень много. Но что если вам нужно выпить 100 разных

102: Тогда наш код превратился бы в огромную простыню, где у каждого объекта нужно вызывать свою собственную функцию, но если они все наследуются от общего класса и переопределяют 1 общую функцию, то можно написать цикл по базовым зельям, где у каждого и вызвать эту fun.

103: Функцию. И тогда будь у нас хоть 1000000 разных зелий в массиве, этот код их выпивания останется Ровно таким же. Всего 2 строчки, блин, пишем 1 раз работает для любых объектов и ситуаций с ними. А я надеюсь, что это видео было очень ценным для вас. Будет здорово, если поставите лайк.

104: Подпишитесь на канал, это правда помогает, также переходите в мой telegram по ссылке в описании.