Парадигма ООП в Factorio, или как натянуть сову на глобус
2024 ж. 7 Нау.
34 672 Рет қаралды
В последнее время стало модно ходить на всякие курсы и учить погромирование. Для помощи непонимающим приводим в ролике пояснение концепций объедко-ориентированного погромирования на примерах из игры Factorio.
Всё сказанное является частным мнением автора. Всем тем кто несогласен, рекомендую записать свой собственный ролик и сидеть с важным видом на диване, а я его покомментирую.
ПОДПИСАТЬСЯ НА КАНАЛ - goo.gl/fBUPy1
DISCORD: / discord
ТЕЛЕГА: t.me/fed1sPlay
ГРУППА ВКОНТАКТЕ: vk.com/fed1splay
Прямая поддержка канала и комплименты:
www.donationalerts.ru/r/fed1s
Поддержка на регулярной основе:
boosty.to/fed1splay
Парни. Кого не устраивает вольная трактовка отношений между объектами в вопросах наследования и ассоциации, можете предложить свой вариант, КАК это можно показать через игровые средства, пусть даже это будет точно также притянуто за уши. Только пожалуйста, давайте такие примеры, которые поймёт даже мой кот :) UML схемы прилагать необязательно. Спасибо :)
Сложна, сложна блять! Нихуя не понимаю!
ну наследование лучше на примере печки, типа вот обычные печки в них нужно ложить уголь, вот печка получше, она тоже потребляет ресурс и выдаёт результат, но подключается уже проводом, а вообще сложно )
Да нет в игре объектов, отвечающих отношению предок-потомок :) Разные тиры объектов - это вариант полиморфизма. Размеченный, и позже расставленный блюпринт - это интерфейс и реализация. Чистого наследования нет. Ближайшая/родственная аналогия - то, что приведено в ролике. Можно было бы вообще эрзац-наследование в форме ассоциаций не рассматривать, но тут в комментах тогда полыхало бы ярче тысячи солнц. Да даже без этого иногда вспыхивает 😂 А я не настолько жесток)
@@fed1splay ты просто понтуешься сложными терминами, признай это.
@@fed1splay Есть наследование! например у тебя есть сборщик первого тира и ты его апгрейдишь на сборщик второго тира. Все продолжает работать рецепт тот же, но немного быстрее и появляются сокеты для модулей. Или например апгрейд белтов. Как стоял желтый белт/был изогнут - так и стал изогнут новый белт. Унаследовал предыдущие настройки (в т.ч. например фильтрацию или логику) от старого белта
Все: что-то там про 8-е марта. Федис: чисто мужицкое пояснение за ООП
Пятница, цифра 8 упала на бок возле дня недели и получилось "ооп"
Вот рецепт, как получить новое видео от Федора: 1) Делаем ролик о программировании, в котором несем дичь. 2) Отправляем в обязательные рекомендации Федору. 3) Наслаждаемся новым видосом.
Как программист, подтверждаю всё сказанное. Сова на глобус натянута успешно
Да ладно. Про наследование херню же сказал.
Я для всех экспертов в наследовании; для сдавших контрольную по ООП, для айтишников с 40-летним стажем и всех прочих переживающих за терминологию специальный закреплённый коммент оставил. Возможно, кто-то даже преисполнится и осознает, что натягивание сов на глобус сопряжено с конфликтами определений и понятий, и неизбежными компромисами между корректной формулировкой и донесением смыслов. С большим интересом посмотрю на пример "в фабриках и конвейерах", который нормальное наследование покажет 😂
Про наследования фигня.
@@fed1splay Ну так всегда так, не возможно точно и детально объяснить X через сопоставление с Y. То же тупое объяснение ООП через машину. Но для начала этого хватит, а если человек захочет, то получит опыт и разберется сам.
@@fed1splay наследование можно на примере жуков использовать.Да и в принципе все понятия ООП. Само понятие "жуки" - это абстракция, базовый абстрактный класс. Абстрактные классы реализации не имеют, соответственно и в игре просто "жука" не увидишь. Есть кусаки и плеваки - это наследники базового класса, имеют методы базового класса "ползти" и "ломать". Нам неизвестно, как они ползают, какими лапками перебирают в какой последовательности и по какому алгоритму, Это инкапсуляция. А вот как "ломают" - вблизи или издали - это уже полиморфизм.
Когда нумеруешь элементы списка с нуля: -да я пограммист-
Просто абстракцию ввели относительно недавно. В далеких 90х у нас было только три пункта 1-3. Так что вполне справедливо, что там 0 ). Для расширения кругозора могу ещё предложить посмотреть на вариацию solid. Не трудно догадаться, что тут аж 5 принципов.
Я бы сказал, формализовали, а не ввели, наверное. Мы же любой класс рассматриваем всегда как абстракцию, а это самая основа. И кстати, на том же msdn у майков, или как они там его щас в learn переименовали, в обучающем разделе давным давно ооп с абстракции рассматривают :) А про солид. Я, честно говоря, даже хз как на примере факторио можно инверсию зависимостей показать. Остальное вроде как-то даже можно притянуть за уши 😂
@@fed1splayДа, у нас абстракция была как само собой разумеющееся. Поэтому в отдельный пункт не выделяли.
@@fed1splayПосмотрел оригинал. Все правильно сделал, что снял этот ролик ))
Ну, является ли абстракция отдельным принципом - тот еще холивар. Основная претензия - абстракция не является именно ООПшной темой, она так или иначе применяется во всех парадигмах программирования. Этакий общий концепт
Всегда верил, что толковые идеи и мысли приходят в голову, либо сидя под яблоней, либо сидя на толчке😂
Можно и на толчке под яблоней
А под кокосовой пально мысли еще быстрее приходят, если мыслитель хорошо знаком с законом всемирного тяготения, особенно когда на эту пальму полез 🦀
Так так, а я думал только у меня котлетки испорченые попались! Федя добро пожаловать в клуб))
надо почаще его испорченными котлетками кормить. :)
Ха-ха. Мне тоже в рекомендациях выпало, и я даже пытался смотреть... минуту. Как хорошо, что есть Фёдор, который может объяснить доступным языком работягам после завода.
Тем не менее, это сова на глобусе)
@@fed1splay Такова участь совы.
Тоже, только я выдержал больше, а потом проклацал.
работягам, приходящим с завода и идущим работать вечером на другой
О, мне буквально сегодня ролик этот попадался по ООП и факторку) полная шляпа
короче что могу сказать, не зря я накатил 3 по 50, хотя бы с умным видом посидел и покивал, как будто что - то в этом шарю😆
Как же я люблю шутки (черту владимиру привет) в подобных видосах
И Юре профессионалу))
5:15 - композиция и агрегация НЕ являются наследованием (is a), это части ассоциации (has a) пример наследования: есть абстрактный класс "модуль", от него наследуется абстрактный класс "модуль продуктивности", а от него наследуется "модуль продуктивности 1 уровня"
Наследование в его "привычной" форме, как вид отношения между объектами, не показать через фабрики и заводы. Ну либо я хз, как :) Равно как и ассоциацию саму по себе. У меня был вариант - апгрейд лент через зелёный чертёж. Но мне это показалось слишком... Странным решением. При этом притянутые за уши композиция и агрегация как вид отношений без проблем ложатся. Пусть и не являются технически наследованием, но их применение вместо прямого наследования - вполне себе сова на глобусе, притянутая за уши :)
@@fed1splayпросто наследование и ассоциация - это разные вещи, которые не стоит объединять) меня бы это точно запутало, если б я был новичком а вот мой пример мне бы зашёл (впрочем, у меня и не было сложностей с наследованием, когда я начинал осваивать ООП)
Твой пример зайдёт, но его не показать практически :) Ну или опять же, я хз как. Логика, которой я руководствовался - банальна. Агрегация предпочтительней композиции, композиция предпочтительней наследования. При этом отсутствует разделение рантайма и компиляции. В итоге наглядное пояснение заходит в тупик. Ну а далее, натягивание совы на глобус. Закреплю, пожалуй, пояснительный коммент касаемо вопроса отношений :) Спасибо
@@fed1splayа что означает "предпочтительнее" в данном контексте?) для чего композиция предпочтительнее наследования?)
Блин, я хочу спать, я не хочу думать 😂 Наследование определяет поведение класса на этапе компиляции, композиция позволяет делать в рантайме, а агрегация через интерфейс и даёт слабую связь. Вот и предпочтения отсюда. Я хз, как это в разных языках реализуется, я не настолько эксперд. Спокойной ночи:)
Это однозначно лайк. Хотя логику с логистикой путаю. Просто Федино творчество нравится. Он хороший)
логика логично будет основой умозаключений, сорян за тавтологию но тут она нужна. логистика - это как доставить умозаключение от мозга к языку
главное столбы с опорами не путай
Раскидал по фактам! Тоже выдавало в рекомендации программирование в Факторке
Спасибо. Все круто описали.
Спасибо огромное за подробное разжевывание) никакого сарказма) спасибо, чуть больше подобных видео, и будет классный обучающий канал!)))
Коротко, ёмко и по делу. Фёдор, это прекрасно!
Композиция и агрегация - это паттерны программирования... Наследование то тут с какого перепугу? Наследование предполагает класс родителя и класс наследника (дочерний класс). Наследник "наследует" поведение родителя, добавляя или изменяя поведение родителя. Наследованием тут лучше сказать так - есть печь. Наследником для печи будет стальная печь, потому как делает тоже самое, но в два раза быстрее. Наследником для стальной печи можно сделать электрическую печь, т.к. она потребляет электроэнергию, а не уголь. Композиция и агрегация - это специальные приемы комбинирования различных парадигмов ООП (наследование, полиморфизм и инкапсуляция + SOLID). Абстракция тоже паттерн, если на то пошло, вы тут называете её принципом единственности ответственности из SOLID
"Как давно вы варите наркотики?" :) Композиция и агрегация - это вид ассоциации. Наравне с наследованием (а при должном натягивании совы на глобус, это можно даже рассмотреть как некое "наследование", что и сделано) ассоциации позволяют строить иерархии отношений типов/классов. Классическое наследование невозможно представить игровыми способами. Приведённый пример с печками - это чистой воды полиморфизм. Наследованием тут будет некоторая печка (любого грейда), как потомок, и базовый класс для печки, как предок, который существует ТОЛЬКО на уровне api игры. Стальная печь не является потомком каменной печи. Электропечь не является потомком стальной. Это просто вариации на тему. Они все потомки одного базового класса - базовой абстрактной печки. Абстракция - это формализованный подход, предполагающий описание необходимых атрибутов и взаимодействий сущностей в рамках некоторой системы, для её абстрактного представления. Например, формирование классов и их отношений/взаимосвязей. Никакого отношения к паттернам абстракция не имеет. При чём тут солид, тоже непонятно. Солид - это набор рекомендаций (принципов), чтобы код как можно меньше походил на винегрет.
@@fed1splay шишечным вареньем вообще представлять какие то сложные механизмы игры примитивными терминами... Тут даже банальная железная руда уже является сложной иерархической сущностью (экземпляром класса) конкретной абстракцией и агрегацией отдельных свойств (тип, спрайт, время выплавки и прочего). Тот, кто первоначально задался идеей "абстрагировать" саму игру, её верхнеуровневые компоненты, до уровней знаний языка программирования... 😭😭 Лучше бы матчасть учил.. не надо так людей пугать. А то будут одни гуманитарии
композиция и агрегация это про отношения экземпляров, а наследование - про переиспользование в видосе произошло натягивание)
Давно так не бомбило)) супер ролик))
ОО, не одному мне этот видос попался, тоже просто помотал и всё на этом
Ютуб ролик предлагал, но даже смореть не стал, нор от этого ролика не удержался - прочитав в названии про сову и глобус, а по факту краткую лекцию послушал, теперь сижу зеваю, надо такого на ночь всегда смотреть.
Великий видос!)
Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма: 1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :) 2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.
Это шедевр!
О, я видел это видео, спасибо за обзор на него!
Молодец!Не опустился до маргинализации и примитивизации темы,а мажоризировал до специальной терминологии😂
Всё ещё достоин
Ура-ура, новые ролики, ведущие за собой потоки праведных рек гнева!
Порождать ненависть - это наша работа!
За 11 минут раскидал по понятиям лучше, чем всякие гуру Пайтона и JS. 😎
Ура, наконец то ФЕДОР ляпин про факторку!
Круто, даже я понял)
А методичка будет? А сдача когда?
Ты контрольную вначале сдай!
Ох, как же у меня бомбануло тогда) Превьюшка шикарная😊
Сам не похвалишь)
И тебе с праздником Федор 😅
Федя, привет. Давно не было видео, какие планы на ближайшее время. Нет желания перепройти боба и ангела? У тебя было, но там вообще что-то очень старое. Если решишь, то хотелось бы увидеть мегабазу на ситиблоках
Во всех гайдах про ООП должно быть: "инкапсуляция - это изоляция", чтобы байтить хомячков на холивары
Это сокрытие!
Вот и забайтил )))
@@fed1splayцитируя классика " Я могу оформить харчок в лицо любому кто говорит что инкапсуляция - это сокрытие, значит ли это что я харчок ?"
Можно взять определение инкапсуляции от майкоософт, и слово Hiding перевести как угодно) Hiding the internal state and functionality of an object and only allowing access through a public set of functions.
@@fed1splayсокрытие многим не нравится в том контексте, когда его имеют в виду именно как модификаторы доступа private. Если же речь про сокрытие внутреннего состояние или по-другому про связывание данных и операций над ними в едином целом (объекте), то всех все устраивает.
В ооп я бы мог сделать так: создать класс ЦЕХ(мощность) с методом "забрать пластины". И создать функцию фабрика(кол-во цехов). И в функции "фабрика" в цикле насоздавать экземплеряов класса ЦЕХ. Подозреваю в фактории это не реализуемо. И все на самом деле сводится к модульному программированию.
Фига ссе, новый ролик, не гецмплецный, от Феди!!!! ❤❤❤❤
Красавчик
Всё понятно, спасибо! Прекрасная подача. При желании ты мог бы преподавать и всё получалось бы.
Ну уж нет)
@fed1splay 😅в идеальном мире)
какая же жесть.... Фёдор, давай ещё!!!11
На наследовании моя сова начала кричать и отбрыкиваться, но в целом годно, натянул :D
А я хз, как чистое наследование как иерархию отношений на чисто игровых примерах показать) Кому надо - обратится к теории, и разберётся в различиях 😂
Кекнул с "Если говорить в общих ЧЕРТАХ". АВХХАХАХАХ
ДОЖДАЛСЯ!!!
Сделай гайд по жд и LTN
классом я бы назвал чертежи, по которым мы строим цеха и прочее, а вот то, что мы построили по этим чертежам - объекты/экземпляры
🔥
О, я тоже видел упомянутый ролик😁
"Испугался? Неее, я абсракцился" 1:44 ПЫСЫ: Опечатка на этом времени :)
Вряд ли это опечатка
Аааа. Ну теперь то всё понятно!
этож как сгореть должно было, чтобы даже ролик запилил)
У меня тоже появлялась мысль, что между логистическими играми и программированием есть что-то общее (даже больше чем с играми где нужно писать код). Прикольно что есть люди, которые разделяют мои беды с башкой. Спасибо за видео! Теперь бессмысленный поток текста который можно не читать (: Даже среди программистов ведутся срачи про ООП (особенно про наследование). Немного отсебятины: Абстракция - это абстрагирование от лишнего. Практический пример: Нам нужно написать программу, которая сортирует яблоки по весу. Для этого программе НЕ нужно знать цвет яблока, размер, форму, где вырос, откуда привезли, сорт. Нам нужно знать только вес, от всего остального мы абстрагируемся. Это и есть абстракция в контексте программирования. Звучит банально и очевидно. Именно по этой причине большинство программистов игнорируют этот принцип и говорят что ООП состоит из 3 принципов, а не из 4. Определение абстракции из видео это скорее определение самого ООП, чем абстракции. Инкапсуляция. Это не простая тема. На практике может иметь не очевидные подводные камни из-за которых этот принцип очень легко нарушить. Инкапсуляция - это защита целостности данных. Есть проблема: у нас есть функция/процедура/метод который работает с данными. При чем данные могут быть не только поступающие из вне, но и внутренние, необходимые для работы метода. Если мы будем из вне менять внутренние данные метода, то это может привести к ошибке/поломке/неправильной работе метода. Одной из причин которая может привести к этой проблеме - глобальные переменные/данные. По этому, глобальные переменные запрещены. Главная цель инкапсуляции - защита целостности данных. Что, как говорилась ранее, не такая простая задача. Однажды нарушение инкапсуляции (из-за глобальных переменных) чуть не привело к войне. Ложно сработала система защиты. Так же была проблема в бортовом компьютере авто, когда блокировалась педаль тормоза. Определение инкапсуляции из видео в целом верная, но это тонкая грань, где легко нарушить инкапсуляцию и стереть грань между классом и структурой данных. Разница между классом и структурой - в классе, методы меняющие внутренние переменные/данные/состояния обязаны обладать сложной логикой, в ином случае это будет нарушением инкапсуляции и это будет уже скорее структурой, чем классом, ведь в таком методе нет никакого смысла. Пример: класс кошелек. Метод меняющий количество денег в кошельке обязан обладать сложной логикой проверяющей что: кошелек не может иметь отрицательное значение, иногда кошелек может иметь максимальное значение и т.д. В случае провала проверки метод обязан либо "кидать исключение"(ошибку), либо, если ситуация типичная, возвращать "код ошибки". В программировании коды ошибок запрещены, вместо них использую boolean(да, нет), либо enum(именованные коды ошибок). В таком случает метод должен именоваться с Try. Возвращать null(ничего) запрещено. Наследование. Популярная тема для срачей. Популярная трактовка наследования устарела и "правильное" определение будет звучать так: Наследование - конкретная реализация таких двух принципов как: полиморфизм и DRY (Запрет на дубляж/KopyPaste). Есть 2 проблемы: 1. Дубляж кода. Чтобы исправить одну ошибку, нужно сделать изменение в нескольких местах, что иногда бывает невозможно. 2. Дубляж кода в if-else. В программировании if-else почти запрещены, почти от всех них можно избавиться с помощью полиморфизма. Главная цель наследования - борьба с дубляжем. Наследование это скорее не принцип ООП, а конкретная реализация двух других принципов. У наследования есть альтернативы: интерфейсы; композиция/агрегация; в языке Go (Golang) есть альтернатива - "Встраивание"; в языке Rust - трейты. Так же есть принцип, который гласит "Composition over inheritance" (Композиция важнее наследования). Это отдельная тема для срачей. Мое мнение, "истина где-то посередине". В большинстве случаев использовать композицию, но не отказываться от наследования (хотя, если отказаться, ничего страшного не должно произойти, ведь есть альтернативы). Наследование - это очень сложный инструмент, неправильное использование которого может привести к проблемам, но в правильных руках проблем быть не должно. Определение наследование из видео вроде верная, но мне кажется что реализовать наследование в Факторио не возможно, если только через чертежи можно натянуто реализовать, а так это вроде возможно реализовать на уровне механик, идея для мода: вносишь изменение в чертеж(класс), и изменение автоматически применяется в дочерних чертежах(производных классах) и дроны начинают автоматически перестраивать старые заводы(объекты) реализующие чертеж. (Говорю как человек никогда не игравший в Факторио) Полиморфизм - способность метода работать с данными разных типов. Есть проблема описанная ранее - дубляж кода. Цель полиморфизма - борьба с ним. Тут мне сказать нечего. В видео все вроде верно.
Отлично.
Посмотрел минуту и уже лайк поставил!
Что-то на сложном
11/10 =))
Жду когда в учебных заведениях основы программирования будут преподавать с помощью факторки. Ну и курсач - это твоя сохранёнка + подробное описание о применённых методах 😂
хорошая презентация, в повер поинт :)
Что я тут делаю? Я же даже не программист... Но всё равно было занятно поглядеть и послушать разъяснения термина, что услышал впервые.
Если простыми словами "моделирование сущностей", про себя думаю, ну нахер😂😂😂😂😂
Красава
Такие же эмоции вызвало, как к месту твой ролик
Я смотрю ролик, всё легко и понятно! После просмотра попросили пересказать суть. Так же я: "эээ, ну там что-то на программистском..."
нормас. одобояем
Ха-ха, нормально пояснил. Я один тот первый видос не видел, как будто)
Зашёл на ютюб, в реках появилось видео про ООП в Факторио. Обновил страницу и в реках появилось твоё видео. Совпадение? Не думаю.
*коммент для продвижения в алгоритмах ютуба* и благодарочка за отличное пояснение =^__^=
Итак посмотрев это видео, как человек далекий от ООП, я не смог определиться я сова или глобус)))
Это интересно, ещё можно попробовать перенести какие то архитектурные паттерны в факторку. Я пробовал на ситиблоках 20х20 сделать слои как в clean архитектуре, но в итоге получилось очень не эффективно из-за ограниченной пропускной способности железной дороги. data - в моей реализации это была как бы база данных/сундуки, в которой были ситиблоки с производимыми и добываемыми ресурсами. domain - тут находились ситиблоки с производственными фабриками . ситиблок запрашивает ресурс из data слоя, обрабатывает его и отправляет обратно в data слой производимый ресурс. ui - это был абстрактный слой , который выводил количество ресурсов из data слоя, я это заменил модом для интерфейса. Но в итоге получилось очень не эффективно, большие проблемы с поездами и ltn модом. Еще пострадал геймплей, так не особо интересно играть, больше похоже на работу, но продумывать это все было интересно.
Чаще бы такие ролики попадались тебе)! Гляди и гайды вернуться)
Тебе лишь бы что-то, что будет пукан мне подпаливать 😂
Нужно самим делать кринжовые ролики, чтобы они попадались fed1splay и он не забрасывал канал
@@fed1splay зато какой шикарный ролик вышел)
Молодец, а теперь поясни за функциональную парадигму в Факторио)
к дизайну заводов в факторио хорошо было бы применено не ООП, а общие принципы дизайна систем - масштабирование, вертикальное, горизонтальное, автоскейлинг, кэширование, мониторинг, логгирование) это же собственно и есть игра про System Design тут ещё можно было бы снять ролик на примере аналогии факторио и книги по Теории Ограничений Систем (Элияху Голдратта) )
Ребята а можно ссылку на ролик, от которого собственно пригорело?)
kzhead.info/sun/nax6k7eIZKWdYIk/bejne.html
Я ни разу не програмист, но ролик тот попался, сложно было и я его не досмотрел. А тут даже чего-то понял)
Федя, у тебя прекрасно получается объяснять. Я который в этом ничего не понимает, что то да понял! Продолжай в том же духе 👍 Видел у тебя на видосах, что ты любишь больше играть в ваниль факторио, чем с модами, но с таким объяснением хотел бы послушать разбор мода Реалистичные Реакторы. Уже 4 день бьюсь над строительством реактора и вообще че-то не получается, не понимаю как стабилизировать 2-а реактора. Один Чернобыль №2 получается)
Я в SE уже 2й год играю 😂
@@fed1splay не ну а, :/ Понял. А в SE есть такой мод? (я про Реакторы)
А где стрим чёрного экрана? Я чет найти не могу. Знаю, что Федя обещал. Не мог же он не выполнить обещание!
🤣🤣🤣🤣🤣🤣🤣🤣Феде реально пукан Бомбануло!первый раз доведённым вижу!
Хотел сначала похейтить, когда увидел тайтл видео, но скажу, что сова натянута на глобус. Правда мне кажется, что те кто не знаком с темой, все же вряд ли что то поняли. Мне понравилось, спасибо, улыбнуло!
У понятиях, в нулевом элементе, ты написал "абсракция")))
то чуство когда пытался установить SFML а наткнулся в коментах на фёдора))
Благое дело, инженер! С мракобесием боришься, просвещение в массы несёшь. Всеотец велел тебе грамоту выписать!
Замечательная идея для видео. Было бы здорово еще разобраться является ли абстракция моделированием, в чем разница между состоянием и структурой, с каких пор композиция из реализации отношения "has-a" перешла в реализацию "is-a", что такое ассоциация и её отличия от наследования
Я уже несколько раз отвечал про проблему представления отношений. Я не смог найти примера в игре для наследования. поэтому... :) Про абстракцию. Майкрософт, например, формулирует абстракцию так: Abstraction - Modeling the relevant attributes and interactions of entities as classes to define an abstract representation of a system.
Примеры наследования: Жуки и Броня как базоовые классы, Кусака, Плевака, как промежуточные, Маленький_Кусака - конкретный класс, ну и всякие абстрактные Топливо, Транспорт, Жидкость итд. И с ними вполне работает полиморфизм: например труба и или бочка принимает любого наследника жидкости (Нефть, Вода), а обратное неверно, вместо конкретной нефти воду подать нельзя
Как только ты обращаешься к прототипу или апи в целом, ты сразу же выходишь за рамки игрового представления :)
К сожалению, получилось отличное объяснение, которое будет просто понять лишь программистам и, одновременно, опытным игрокам в факторио. Домохозяйка и человек-сосед грустно проходят мимо.
Лайк за Вована !
Тысяча чертей!
Давай ещё уроки!
О, я смотрел тот видос, на скорости x2, быгыгы. Да, действительно, факторка там будто для кликбейта, чисто в конце, да и наследование странно визуализировано, хоть и сам аффтар ремарку сделал. Но для объяснения тем, кто не шарит, такое недопустимо
А для тех, кому не пришло в рекомендациях, можно ссылку на изначальное видео, от которого Фёдора бомбануло?
Бальдэжное видэо. Хороший стримлер бамбид на интернет + интересный контент. Мог бы даже потеребонькать, но самовнушением приписал руке свойство абстракции и теперь она не стыкуется с реальными предметами. Буду теперь думать как это исправить. Главное - в процессе не приписать подобное свойство мозгу, а то ещё выйду из матрицы раньше времени, и не смогу пронаблюдать сей дурдом до логичного финала.
Когда автор того видеоролика про ООП показал заводы, на которые подаётся руда, которая переплавляется в пластины внутри цеха по производству модулей 1 уровня(и прочих), я понял что тот автор вообще не умеет применять ООП в factorio. И это действительно натягивание совы на глобус. А Фёдор рассказал очень грамотно, и самое главное с наглядными и простыми примерами. Я как программист одобряю всё показанное.
Норм)) давай теперь принципы SOLID))
Ля, мне тоже ролик тот попался, но отложил. Так что пойду тоже "посижу" и посмотрю)
Посидеть и отложить - это важно)
Надо ещё эксперименты провести с постройкой базы по различным паттернам программирования, адаптируя их под факторку
Там чуть ли не половину GoF паттернов можно при желании натянуть) Вопрос только, какой смысл
GoF - Globus on Filin? 😂
@@Adder_ai in
Блин, только сейчас увидел это видео) Тоже видел этого парня и решил сделать свое видео, но ты сделал это быстрее :((
Жду объяснение всего с++ на примере факторки за 2 часа от ждуна до сеньора
тоже набрал 10 космическую с того ролика 😂
Всё, бросаю факторку, пойду Кнута почитаю
😂👍
У меня есть более экзотический пример. Рандомный чел из интернета советовал мне Факторио, чтобы разобраться с конкурентностью и параллелизмом в языках программирования
Уважаемый Федор, здравствуйте! Зачем при объяснении, сути полиморфизма, была вставлена картинка Владимира, да ещё в купе с фразой, "в общих чертах"? Я пока ржал, не понял сути полиморфизма. По крайней мере, не понял ваших объяснений! Шутка зачётная! Спасибо за толковый контент!