Парадигма ООП в Factorio, или как натянуть сову на глобус

В последнее время стало модно ходить на всякие курсы и учить погромирование. Для помощи непонимающим приводим в ролике пояснение концепций объедко-ориентированного погромирования на примерах из игры Factorio.
Всё сказанное является частным мнением автора. Всем тем кто несогласен, рекомендую записать свой собственный ролик и сидеть с важным видом на диване, а я его покомментирую.
ПОДПИСАТЬСЯ НА КАНАЛ - goo.gl/fBUPy1
DISCORD: / discord
ТЕЛЕГА: t.me/fed1sPlay
ГРУППА ВКОНТАКТЕ: fed1splay
Прямая поддержка канала и комплименты:
www.donationalerts.ru/r/fed1s
Поддержка на регулярной основе:
boosty.to/fed1splay

[@fed1splay]

Парни. Кого не устраивает вольная трактовка отношений между объектами в вопросах наследования и ассоциации, можете предложить свой вариант, КАК это можно показать через игровые средства, пусть даже это будет точно также притянуто за уши. Только пожалуйста, давайте такие примеры, которые поймёт даже мой кот :) UML схемы прилагать необязательно. Спасибо :)

[@seaways404]

Сложна, сложна блять! Нихуя не понимаю!

[@user-in8hp5vu6h]

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

[@fed1splay]

Да нет в игре объектов, отвечающих отношению предок-потомок :) Разные тиры объектов - это вариант полиморфизма. Размеченный, и позже расставленный блюпринт - это интерфейс и реализация. Чистого наследования нет. Ближайшая/родственная аналогия - то, что приведено в ролике. Можно было бы вообще эрзац-наследование в форме ассоциаций не рассматривать, но тут в комментах тогда полыхало бы ярче тысячи солнц. Да даже без этого иногда вспыхивает 😂 А я не настолько жесток)

[@seaways404]

@@fed1splay ты просто понтуешься сложными терминами, признай это.

[@MrBkorel]

@@fed1splay Есть наследование! например у тебя есть сборщик первого тира и ты его апгрейдишь на сборщик второго тира. Все продолжает работать рецепт тот же, но немного быстрее и появляются сокеты для модулей. Или например апгрейд белтов. Как стоял желтый белт/был изогнут - так и стал изогнут новый белт. Унаследовал предыдущие настройки (в т.ч. например фильтрацию или логику) от старого белта

[@zhanluka]

Все: что-то там про 8-е марта. Федис: чисто мужицкое пояснение за ООП

[@Prizrak_Leonis]

Пятница, цифра 8 упала на бок возле дня недели и получилось "ооп"

[@steveq1938]

Вот рецепт, как получить новое видео от Федора: 1) Делаем ролик о программировании, в котором несем дичь. 2) Отправляем в обязательные рекомендации Федору. 3) Наслаждаемся новым видосом.

[@EgoricNoc]

Когда нумеруешь элементы списка с нуля: -да я пограммист-

[@olegzorin3911]

Просто абстракцию ввели относительно недавно. В далеких 90х у нас было только три пункта 1-3. Так что вполне справедливо, что там 0 ). Для расширения кругозора могу ещё предложить посмотреть на вариацию solid. Не трудно догадаться, что тут аж 5 принципов.

[@fed1splay]

Я бы сказал, формализовали, а не ввели, наверное. Мы же любой класс рассматриваем всегда как абстракцию, а это самая основа. И кстати, на том же msdn у майков, или как они там его щас в learn переименовали, в обучающем разделе давным давно ооп с абстракции рассматривают :) А про солид. Я, честно говоря, даже хз как на примере факторио можно инверсию зависимостей показать. Остальное вроде как-то даже можно притянуть за уши 😂

[@olegzorin3911]

@@fed1splayДа, у нас абстракция была как само собой разумеющееся. Поэтому в отдельный пункт не выделяли.

[@olegzorin3911]

@@fed1splayПосмотрел оригинал. Все правильно сделал, что снял этот ролик ))

[@sylphur2320]

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

[@bebra._.228]

Как программист, подтверждаю всё сказанное. Сова на глобус натянута успешно

[@dima_on]

Да ладно. Про наследование херню же сказал.

[@fed1splay]

Я для всех экспертов в наследовании; для сдавших контрольную по ООП, для айтишников с 40-летним стажем и всех прочих переживающих за терминологию специальный закреплённый коммент оставил. Возможно, кто-то даже преисполнится и осознает, что натягивание сов на глобус сопряжено с конфликтами определений и понятий, и неизбежными компромисами между корректной формулировкой и донесением смыслов. С большим интересом посмотрю на пример "в фабриках и конвейерах", который нормальное наследование покажет 😂

[@user-yc7ow9wx7i]

Про наследования фигня.

[@shynekomaid]

@@fed1splay Ну так всегда так, не возможно точно и детально объяснить X через сопоставление с Y. То же тупое объяснение ООП через машину. Но для начала этого хватит, а если человек захочет, то получит опыт и разберется сам.

[@user-sr4nw2iu2u]

@@fed1splay наследование можно на примере жуков использовать.Да и в принципе все понятия ООП. Само понятие "жуки" - это абстракция, базовый абстрактный класс. Абстрактные классы реализации не имеют, соответственно и в игре просто "жука" не увидишь. Есть кусаки и плеваки - это наследники базового класса, имеют методы базового класса "ползти" и "ломать". Нам неизвестно, как они ползают, какими лапками перебирают в какой последовательности и по какому алгоритму, Это инкапсуляция. А вот как "ломают" - вблизи или издали - это уже полиморфизм.

[@World_Spectrator]

Всегда верил, что толковые идеи и мысли приходят в голову, либо сидя под яблоней, либо сидя на толчке😂

[@user-st6rz6du5n]

Можно и на толчке под яблоней

[@Prizrak_Leonis]

А под кокосовой пально мысли еще быстрее приходят, если мыслитель хорошо знаком с законом всемирного тяготения, особенно когда на эту пальму полез 🦀

[@user-eb2ir7wm9f]

Так так, а я думал только у меня котлетки испорченые попались! Федя добро пожаловать в клуб))

[@RA7581]

надо почаще его испорченными котлетками кормить. :)

[@casper608]

Ха-ха. Мне тоже в рекомендациях выпало, и я даже пытался смотреть... минуту. Как хорошо, что есть Фёдор, который может объяснить доступным языком работягам после завода.

[@fed1splay]

Тем не менее, это сова на глобусе)

[@casper608]

@@fed1splay Такова участь совы.

[@p.k.r.7963]

Тоже, только я выдержал больше, а потом проклацал.

[@cirno_the_mediocrity]

работягам, приходящим с завода и идущим работать вечером на другой

[@user-sd6ib5kd5x]

О, мне буквально сегодня ролик этот попадался по ООП и факторку) полная шляпа

[@groomgo]

короче что могу сказать, не зря я накатил 3 по 50, хотя бы с умным видом посидел и покивал, как будто что - то в этом шарю😆

[@batpro7564]

Как же я люблю шутки (черту владимиру привет) в подобных видосах

[@Lexys3230]

И Юре профессионалу))

[@vinograd7857]

Спасибо. Все круто описали.

[@nikelsad]

Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма: 1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :) 2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.

[@tushkan9691]

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

[@MrHalfint]

5:15 - композиция и агрегация НЕ являются наследованием (is a), это части ассоциации (has a) пример наследования: есть абстрактный класс "модуль", от него наследуется абстрактный класс "модуль продуктивности", а от него наследуется "модуль продуктивности 1 уровня"

[@fed1splay]

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

[@MrHalfint]

@@fed1splayпросто наследование и ассоциация - это разные вещи, которые не стоит объединять) меня бы это точно запутало, если б я был новичком а вот мой пример мне бы зашёл (впрочем, у меня и не было сложностей с наследованием, когда я начинал осваивать ООП)

[@fed1splay]

Твой пример зайдёт, но его не показать практически :) Ну или опять же, я хз как. Логика, которой я руководствовался - банальна. Агрегация предпочтительней композиции, композиция предпочтительней наследования. При этом отсутствует разделение рантайма и компиляции. В итоге наглядное пояснение заходит в тупик. Ну а далее, натягивание совы на глобус. Закреплю, пожалуй, пояснительный коммент касаемо вопроса отношений :) Спасибо

[@MrHalfint]

@@fed1splayа что означает "предпочтительнее" в данном контексте?) для чего композиция предпочтительнее наследования?)

[@fed1splay]

Блин, я хочу спать, я не хочу думать 😂 Наследование определяет поведение класса на этапе компиляции, композиция позволяет делать в рантайме, а агрегация через интерфейс и даёт слабую связь. Вот и предпочтения отсюда. Я хз, как это в разных языках реализуется, я не настолько эксперд. Спокойной ночи:)

[@user-su5bf9cn9t]

Это однозначно лайк. Хотя логику с логистикой путаю. Просто Федино творчество нравится. Он хороший)

[@user-uv8gc2gq3k]

логика логично будет основой умозаключений, сорян за тавтологию но тут она нужна. логистика - это как доставить умозаключение от мозга к языку

[@rar24]

главное столбы с опорами не путай

[@mister_Iks]

Давно так не бомбило)) супер ролик))

[@nagirov]

Коротко, ёмко и по делу. Фёдор, это прекрасно!

[@Triariy89]

Композиция и агрегация - это паттерны программирования... Наследование то тут с какого перепугу? Наследование предполагает класс родителя и класс наследника (дочерний класс). Наследник "наследует" поведение родителя, добавляя или изменяя поведение родителя. Наследованием тут лучше сказать так - есть печь. Наследником для печи будет стальная печь, потому как делает тоже самое, но в два раза быстрее. Наследником для стальной печи можно сделать электрическую печь, т.к. она потребляет электроэнергию, а не уголь. Композиция и агрегация - это специальные приемы комбинирования различных парадигмов ООП (наследование, полиморфизм и инкапсуляция + SOLID). Абстракция тоже паттерн, если на то пошло, вы тут называете её принципом единственности ответственности из SOLID

[@fed1splay]

"Как давно вы варите наркотики?" :) Композиция и агрегация - это вид ассоциации. Наравне с наследованием (а при должном натягивании совы на глобус, это можно даже рассмотреть как некое "наследование", что и сделано) ассоциации позволяют строить иерархии отношений типов/классов. Классическое наследование невозможно представить игровыми способами. Приведённый пример с печками - это чистой воды полиморфизм. Наследованием тут будет некоторая печка (любого грейда), как потомок, и базовый класс для печки, как предок, который существует ТОЛЬКО на уровне api игры. Стальная печь не является потомком каменной печи. Электропечь не является потомком стальной. Это просто вариации на тему. Они все потомки одного базового класса - базовой абстрактной печки. Абстракция - это формализованный подход, предполагающий описание необходимых атрибутов и взаимодействий сущностей в рамках некоторой системы, для её абстрактного представления. Например, формирование классов и их отношений/взаимосвязей. Никакого отношения к паттернам абстракция не имеет. При чём тут солид, тоже непонятно. Солид - это набор рекомендаций (принципов), чтобы код как можно меньше походил на винегрет.

[@Triariy89]

@@fed1splay шишечным вареньем вообще представлять какие то сложные механизмы игры примитивными терминами... Тут даже банальная железная руда уже является сложной иерархической сущностью (экземпляром класса) конкретной абстракцией и агрегацией отдельных свойств (тип, спрайт, время выплавки и прочего). Тот, кто первоначально задался идеей "абстрагировать" саму игру, её верхнеуровневые компоненты, до уровней знаний языка программирования... 😭😭 Лучше бы матчасть учил.. не надо так людей пугать. А то будут одни гуманитарии

[@darkfrei2]

О, я видел это видео, спасибо за обзор на него!

[@rar24]

композиция и агрегация это про отношения экземпляров, а наследование - про переиспользование в видосе произошло натягивание)

[@muskonobim9477]

У меня тоже появлялась мысль, что между логистическими играми и программированием есть что-то общее (даже больше чем с играми где нужно писать код). Прикольно что есть люди, которые разделяют мои беды с башкой. Спасибо за видео! Теперь бессмысленный поток текста который можно не читать (: Даже среди программистов ведутся срачи про ООП (особенно про наследование). Немного отсебятины: Абстракция - это абстрагирование от лишнего. Практический пример: Нам нужно написать программу, которая сортирует яблоки по весу. Для этого программе НЕ нужно знать цвет яблока, размер, форму, где вырос, откуда привезли, сорт. Нам нужно знать только вес, от всего остального мы абстрагируемся. Это и есть абстракция в контексте программирования. Звучит банально и очевидно. Именно по этой причине большинство программистов игнорируют этот принцип и говорят что ООП состоит из 3 принципов, а не из 4. Определение абстракции из видео это скорее определение самого ООП, чем абстракции. Инкапсуляция. Это не простая тема. На практике может иметь не очевидные подводные камни из-за которых этот принцип очень легко нарушить. Инкапсуляция - это защита целостности данных. Есть проблема: у нас есть функция/процедура/метод который работает с данными. При чем данные могут быть не только поступающие из вне, но и внутренние, необходимые для работы метода. Если мы будем из вне менять внутренние данные метода, то это может привести к ошибке/поломке/неправильной работе метода. Одной из причин которая может привести к этой проблеме - глобальные переменные/данные. По этому, глобальные переменные запрещены. Главная цель инкапсуляции - защита целостности данных. Что, как говорилась ранее, не такая простая задача. Однажды нарушение инкапсуляции (из-за глобальных переменных) чуть не привело к войне. Ложно сработала система защиты. Так же была проблема в бортовом компьютере авто, когда блокировалась педаль тормоза. Определение инкапсуляции из видео в целом верная, но это тонкая грань, где легко нарушить инкапсуляцию и стереть грань между классом и структурой данных. Разница между классом и структурой - в классе, методы меняющие внутренние переменные/данные/состояния обязаны обладать сложной логикой, в ином случае это будет нарушением инкапсуляции и это будет уже скорее структурой, чем классом, ведь в таком методе нет никакого смысла. Пример: класс кошелек. Метод меняющий количество денег в кошельке обязан обладать сложной логикой проверяющей что: кошелек не может иметь отрицательное значение, иногда кошелек может иметь максимальное значение и т.д. В случае провала проверки метод обязан либо "кидать исключение"(ошибку), либо, если ситуация типичная, возвращать "код ошибки". В программировании коды ошибок запрещены, вместо них использую boolean(да, нет), либо enum(именованные коды ошибок). В таком случает метод должен именоваться с Try. Возвращать null(ничего) запрещено. Наследование. Популярная тема для срачей. Популярная трактовка наследования устарела и "правильное" определение будет звучать так: Наследование - конкретная реализация таких двух принципов как: полиморфизм и DRY (Запрет на дубляж/KopyPaste). Есть 2 проблемы: 1. Дубляж кода. Чтобы исправить одну ошибку, нужно сделать изменение в нескольких местах, что иногда бывает невозможно. 2. Дубляж кода в if-else. В программировании if-else почти запрещены, почти от всех них можно избавиться с помощью полиморфизма. Главная цель наследования - борьба с дубляжем. Наследование это скорее не принцип ООП, а конкретная реализация двух других принципов. У наследования есть альтернативы: интерфейсы; композиция/агрегация; в языке Go (Golang) есть альтернатива - "Встраивание"; в языке Rust - трейты. Так же есть принцип, который гласит "Composition over inheritance" (Композиция важнее наследования). Это отдельная тема для срачей. Мое мнение, "истина где-то посередине". В большинстве случаев использовать композицию, но не отказываться от наследования (хотя, если отказаться, ничего страшного не должно произойти, ведь есть альтернативы). Наследование - это очень сложный инструмент, неправильное использование которого может привести к проблемам, но в правильных руках проблем быть не должно. Определение наследование из видео вроде верная, но мне кажется что реализовать наследование в Факторио не возможно, если только через чертежи можно натянуто реализовать, а так это вроде возможно реализовать на уровне механик, идея для мода: вносишь изменение в чертеж(класс), и изменение автоматически применяется в дочерних чертежах(производных классах) и дроны начинают автоматически перестраивать старые заводы(объекты) реализующие чертеж. (Говорю как человек никогда не игравший в Факторио) Полиморфизм - способность метода работать с данными разных типов. Есть проблема описанная ранее - дубляж кода. Цель полиморфизма - борьба с ним. Тут мне сказать нечего. В видео все вроде верно.

[@Fuzzy_HD]

Кекнул с "Если говорить в общих ЧЕРТАХ". АВХХАХАХАХ

[@IYBeats]

Раскидал по фактам! Тоже выдавало в рекомендации программирование в Факторке

[@Ostrov1010]

Молодец!Не опустился до маргинализации и примитивизации темы,а мажоризировал до специальной терминологии😂

[@Ihor_Semenenko]

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

[@Leshocs1]

Фига ссе, новый ролик, не гецмплецный, от Феди!!!! ❤❤❤❤

[@LE0p01d]

7:50 Это Владимир! И он чертовски хорошо выглядит!

[@OlegShinder]

ОО, не одному мне этот видос попался, тоже просто помотал и всё на этом

[@pronub9743]

Ура-ура, новые ролики, ведущие за собой потоки праведных рек гнева!

[@fed1splay]

Порождать ненависть - это наша работа!

[@borismirzakhanyan3545]

Во всех гайдах про ООП должно быть: "инкапсуляция - это изоляция", чтобы байтить хомячков на холивары

[@fed1splay]

Это сокрытие!

[@TheTempterable]

Вот и забайтил )))

[@Rainbow_song]

​@@fed1splayцитируя классика " Я могу оформить харчок в лицо любому кто говорит что инкапсуляция - это сокрытие, значит ли это что я харчок ?"

[@fed1splay]

Можно взять определение инкапсуляции от майкоософт, и слово Hiding перевести как угодно) Hiding the internal state and functionality of an object and only allowing access through a public set of functions.

[@brinza888]

@@fed1splayсокрытие многим не нравится в том контексте, когда его имеют в виду именно как модификаторы доступа private. Если же речь про сокрытие внутреннего состояние или по-другому про связывание данных и операций над ними в едином целом (объекте), то всех все устраивает.

[@user-mi1lp5wo2o]

Всё ещё достоин

[@Kazakk47]

И тебе с праздником Федор 😅

[@user-pj1nk2xf7j]

Круто, даже я понял)

[@areswild4735]

какая же жесть.... Фёдор, давай ещё!!!11

[@turbanov]

Ох, как же у меня бомбануло тогда) Превьюшка шикарная😊

[@fed1splay]

Сам не похвалишь)

[@sbknet5080]

Ура, наконец то ФЕДОР ляпин про факторку!

[@WladySpb]

О, я тоже видел упомянутый ролик😁

[@umnedhacker567]

Великий видос!)

[@lastloony]

Это шедевр!

[@roflin4ik]

классом я бы назвал чертежи, по которым мы строим цеха и прочее, а вот то, что мы построили по этим чертежам - объекты/экземпляры

[@mihailmitrofanov4304]

Федя, привет. Давно не было видео, какие планы на ближайшее время. Нет желания перепройти боба и ангела? У тебя было, но там вообще что-то очень старое. Если решишь, то хотелось бы увидеть мегабазу на ситиблоках

[@mygodishe]

В ооп я бы мог сделать так: создать класс ЦЕХ(мощность) с методом "забрать пластины". И создать функцию фабрика(кол-во цехов). И в функции "фабрика" в цикле насоздавать экземплеряов класса ЦЕХ. Подозреваю в фактории это не реализуемо. И все на самом деле сводится к модульному программированию.

[@romangolumbevskiy7268]

За 11 минут раскидал по понятиям лучше, чем всякие гуру Пайтона и JS. 😎

[@timbeopwonloginov3648]

*коммент для продвижения в алгоритмах ютуба* и благодарочка за отличное пояснение =^__^=

[@andre928]

Отлично.

[@Place_for_your_advertisement.]

*Лучшая абстракция в Factorio - облачная архитектура, где "облако" - это - буквально - облако дронов,* которые растаскивают продукцию между логистическими сундуками, а каждый производственный юнит - просто производящее здание (!одно!) + логистические сундуки с манипуляторами (или, если нужна жидкость - одно производящее здание + баки + упаковщики/распаковщики бочек, которые опять же - при помощи логистических сундуков с манипуляторами и дронов - автоматически растаскиваются). Это имба. Основная фича такой архитектуры - убойная гибкость и масштабируемость, а равно и автобалансировка (пусть и субоптимальная) объёмов выпуска продукции. Развернуть ещё один чертёж - производственное здание заданного типа с снабжением "из воздуха" - элементарно, на любой локации, простым Ctrl+C - Ctrl+V, резко нарастив производство/переработку чего угодно. Добавить к существующему производству ещё какое-то? - Элементарно: постройка + сундуки + дроны всё принесут. Накосячить с организацией построек - не страшно: запросто всё можно перестроить, т.к. связей между зданиями - вообще никаких, скажем производство красных микросхем никак не привязано к производству зелёных, вся наличная продукция доступна глобально. Субоптимальная автобалансировка - особенно хороша тем, что вообще не напрягает мозг: сколько нужно выпускать одной продукции, для выпуска второй чесать репу не надо. Из "глобального" "облака" - берётся сколько нужно или всё, что есть. Поэтому достигается субоптимальное распределение во времени: если, скажем, для двух типов продукции нужны шестерёнки, то как только произведено нужное количество продукции первого типа, все мощности производства шестерёнок автоматически переключаются на снабжение производств продукции второго типа: продукция, необходимая в нескольких типах производств автоматически перераспределяется в пользу дефицитных при достижении насыщения в остальных, а не тупо валяется - как при жёстких связях с конвейерами. Плюс задействуется почти оптимальный маршрут. Особенно, если учесть, что конвейеры движутся с константной скоростью по некоторому маршруту (с обходом препятствий), а дроны летят по прямой - разница между путём и перемещением - школьный курс физики - налицо: конвейеры - путь, а дроны - перемещение (всегда по прямой из пункта A в Б). Недостатков, примерно 3: 1) Требует много энергии и дронов 2) Имеет тенденцию к деградации в отношении снабжения сырьём - обратная сторона кратчайшего маршрута при доставке: ближайший ресурс истощился -> следующий будет дальше 3) Субоптимально, а не оптимально. Т.е. распределение близко к оптимальному но никогда не является оптимальным. Особенно остро это проявляется при обострении дефицита: во входных сундуках начинают накапливаться неполные объёмы, т.е. в нескольких производственных зданиях - суммарно - есть объём входных ресурсов для производства по заданному рецепту, но ни в одном из них - взятом в отдельности - он не является достаточным: если бы все эти ресурсы были на входе у одного здания - производство началось бы, а де-факто, оно не начинается, т.к. они по чуть-чуть распределены у всех.

[@user-yw6nd4rq3i]

фсе круто, но фпсу карачун. но на кластере из суперкомпуктеров наверно будет норм

[@MyXcompany]

Посмотрел минуту и уже лайк поставил!

[@Asmodian1990]

Аааа. Ну теперь то всё понятно!

[@joehart7382]

ДОЖДАЛСЯ!!!

[@user-tc9tq6cv5l]

Что-то на сложном

[@antonbakaiev]

Если простыми словами "моделирование сущностей", про себя думаю, ну нахер😂😂😂😂😂

[@compolomus9719]

этож как сгореть должно было, чтобы даже ролик запилил)

[@Adder_ai]

А методичка будет? А сдача когда?

[@fed1splay]

Ты контрольную вначале сдай!

[@Ilvrak]

к дизайну заводов в факторио хорошо было бы применено не ООП, а общие принципы дизайна систем - масштабирование, вертикальное, горизонтальное, автоскейлинг, кэширование, мониторинг, логгирование) это же собственно и есть игра про System Design тут ещё можно было бы снять ролик на примере аналогии факторио и книги по Теории Ограничений Систем (Элияху Голдратта) )

[@avalon1000]

🤣🤣🤣🤣🤣🤣🤣🤣Феде реально пукан Бомбануло!первый раз доведённым вижу!

[@RA7581]

хорошая презентация, в повер поинт :)

[@nekay9561]

Зашёл на ютюб, в реках появилось видео про ООП в Факторио. Обновил страницу и в реках появилось твоё видео. Совпадение? Не думаю.

[@alexmalov8023]

Красавчик

[@user-pd8vg1gd5z]

Примеры наследования: Жуки и Броня как базоовые классы, Кусака, Плевака, как промежуточные, Маленький_Кусака - конкретный класс, ну и всякие абстрактные Топливо, Транспорт, Жидкость итд. И с ними вполне работает полиморфизм: например труба и или бочка принимает любого наследника жидкости (Нефть, Вода), а обратное неверно, вместо конкретной нефти воду подать нельзя

[@fed1splay]

Как только ты обращаешься к прототипу или апи в целом, ты сразу же выходишь за рамки игрового представления :)

[@TheVidisi]

Это интересно, ещё можно попробовать перенести какие то архитектурные паттерны в факторку. Я пробовал на ситиблоках 20х20 сделать слои как в clean архитектуре, но в итоге получилось очень не эффективно из-за ограниченной пропускной способности железной дороги. data - в моей реализации это была как бы база данных/сундуки, в которой были ситиблоки с производимыми и добываемыми ресурсами. domain - тут находились ситиблоки с производственными фабриками . ситиблок запрашивает ресурс из data слоя, обрабатывает его и отправляет обратно в data слой производимый ресурс. ui - это был абстрактный слой , который выводил количество ресурсов из data слоя, я это заменил модом для интерфейса. Но в итоге получилось очень не эффективно, большие проблемы с поездами и ltn модом. Еще пострадал геймплей, так не особо интересно играть, больше похоже на работу, но продумывать это все было интересно.

[@MaksimMelnik]

Жду когда в учебных заведениях основы программирования будут преподавать с помощью факторки. Ну и курсач - это твоя сохранёнка + подробное описание о применённых методах 😂

[@danonishuk8961]

Такие же эмоции вызвало, как к месту твой ролик

[@yukiyasudo2356]

Федя, у тебя прекрасно получается объяснять. Я который в этом ничего не понимает, что то да понял! Продолжай в том же духе 👍 Видел у тебя на видосах, что ты любишь больше играть в ваниль факторио, чем с модами, но с таким объяснением хотел бы послушать разбор мода Реалистичные Реакторы. Уже 4 день бьюсь над строительством реактора и вообще че-то не получается, не понимаю как стабилизировать 2-а реактора. Один Чернобыль №2 получается)

[@fed1splay]

Я в SE уже 2й год играю 😂

[@yukiyasudo2356]

@@fed1splay не ну а, :/ Понял. А в SE есть такой мод? (я про Реакторы)

[@esusplay7127]

Благое дело, инженер! С мракобесием боришься, просвещение в массы несёшь. Всеотец велел тебе грамоту выписать!

[@zelldor2719]

Наследование != Ассоциация -> Агрегация, Композиция. Даже в языке UML это разные виды связей.

[@AndreySold]

Я смотрю ролик, всё легко и понятно! После просмотра попросили пересказать суть. Так же я: "эээ, ну там что-то на программистском..."

[@evgeniyevgeniy1372]

У меня есть более экзотический пример. Рандомный чел из интернета советовал мне Факторио, чтобы разобраться с конкурентностью и параллелизмом в языках программирования

[@user-ym9rc1qj7l]

нормас. одобояем

[@Demon-gr3ks]

Красава

[@user-hd8oy9xp8m]

Давай ещё уроки!

[@Ilvrak]

в том видео речь не о том, как объяснить ООП на примере факторио, а о том, как применить принципы ООП в дизайне заводов.

[@rainbowGrizz]

Ха-ха, нормально пояснил. Я один тот первый видос не видел, как будто)

[@IvanSemin]

тоже набрал 10 космическую с того ролика 😂

[@user-vq4yz9jl1w]

Итак посмотрев это видео, как человек далекий от ООП, я не смог определиться я сова или глобус)))

[@Maki-gz3ec]

Лол, когда у других летсплейщиков горит жопа они идут и выливают тонны дерьма, когда жопа горит у летсплейщиков Факторки он решает сесть и выдать базу на уровни лексий из уника.

[@ruzarh]

Хотел сначала похейтить, когда увидел тайтл видео, но скажу, что сова натянута на глобус. Правда мне кажется, что те кто не знаком с темой, все же вряд ли что то поняли. Мне понравилось, спасибо, улыбнуло!

[@kuzmich743]

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

[@DERJNDZE]

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

[@vladatom]

Всё понятно, спасибо! Прекрасная подача. При желании ты мог бы преподавать и всё получалось бы.

[@fed1splay]

Ну уж нет)

[@vladatom]

@fed1splay 😅в идеальном мире)

[@TheRealFaner]

"Испугался? Неее, я абсракцился" 1:44 ПЫСЫ: Опечатка на этом времени :)

[@AXSMEBEL]

Вряд ли это опечатка

[@user-kx2fe2sg9o]

🔥

[@s-v-4857]

Когда автор того видеоролика про ООП показал заводы, на которые подаётся руда, которая переплавляется в пластины внутри цеха по производству модулей 1 уровня(и прочих), я понял что тот автор вообще не умеет применять ООП в factorio. И это действительно натягивание совы на глобус. А Фёдор рассказал очень грамотно, и самое главное с наглядными и простыми примерами. Я как программист одобряю всё показанное.

[@eirpile]

Бальдэжное видэо. Хороший стримлер бамбид на интернет + интересный контент. Мог бы даже потеребонькать, но самовнушением приписал руке свойство абстракции и теперь она не стыкуется с реальными предметами. Буду теперь думать как это исправить. Главное - в процессе не приписать подобное свойство мозгу, а то ещё выйду из матрицы раньше времени, и не смогу пронаблюдать сей дурдом до логичного финала.

[@multiprogramm]

На наследовании моя сова начала кричать и отбрыкиваться, но в целом годно, натянул :D

[@fed1splay]

А я хз, как чистое наследование как иерархию отношений на чисто игровых примерах показать) Кому надо - обратится к теории, и разберётся в различиях 😂

[@white73h4]

Норм)) давай теперь принципы SOLID))

[@rinko6406]

Что я тут делаю? Я же даже не программист... Но всё равно было занятно поглядеть и послушать разъяснения термина, что услышал впервые.

[@tassadarthehightemplar754]

А для тех, кому не пришло в рекомендациях, можно ссылку на изначальное видео, от которого Фёдора бомбануло?

[@Pan__bratella]

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

[@ProCto_Filya]

то чуство когда пытался установить SFML а наткнулся в коментах на фёдора))

[@blezzrot4115]

теперь нужна парадигма ФП (функциональное программирование) в factorio

[@user-tj9pc4gz9s]

Вся фабрика суть - одна большая do-нотация, перелопачивающая на потоке монады-ресурсы?

[@maksimsemenov3248]

Замечательная идея для видео. Было бы здорово еще разобраться является ли абстракция моделированием, в чем разница между состоянием и структурой, с каких пор композиция из реализации отношения "has-a" перешла в реализацию "is-a", что такое ассоциация и её отличия от наследования

[@fed1splay]

Я уже несколько раз отвечал про проблему представления отношений. Я не смог найти примера в игре для наследования. поэтому... :) Про абстракцию. Майкрософт, например, формулирует абстракцию так: Abstraction - Modeling the relevant attributes and interactions of entities as classes to define an abstract representation of a system.

[@undefinedundefined5924]

К сожалению, получилось отличное объяснение, которое будет просто понять лишь программистам и, одновременно, опытным игрокам в факторио. Домохозяйка и человек-сосед грустно проходят мимо.

[@hedgehogsch.7270]

Молодец, а теперь поясни за функциональную парадигму в Факторио)

[@nickzub6050]

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

[@fed1splay]

Мы так до партийности в искусстве дойдём :) Никто и не говорил, что аналогия - это единственно верный и правильный способ познания. Скорее наоборот, все аналогии лживы. Прикол в том, что очень часто аналогии помогают ухватить суть. Лет 200 назад, когда я изучал интегралы на математике, до меня очень туго доходило, как "это всё работает". Но когда нам донесли суть через, скажем так, аналогию... через площадь фигуры, которая была нарисована, всё встало на свои места. Более того, в видосе я честно сказал, что это натягивание совы на глобус :) И печки тут - вполне неплохой пример. Есть примеры в разы хуже 😂

[@nickzub6050]

​@@fed1splay Нуу, не так резко: аналогии не только лживы, но и в то же время верны, иначе зачем они вообще нужны) Просто есть границы, где аналогия верна, а где обращается в ложь, и на мой чисто субъективный взгляд аналогия это хорошее, но несамостоятельное дополнение к познанию, к практике Ну как просто набор аналогий в факторио и ООП подходе - норм, точно сильно лучше много другого, хотя на мой душный программистерский взгляд есть пара неточностей :)

[@fed1splay]

@@nickzub6050 да все мы душные. Мне надо подобные ролики в раздел "юмор" наверное определять :)

[@uis246]

Проблема в том, что factorio больше похоже на разработку интегральных схем, чем на программирование. Ну или на data-oriented programming.

[@ReeZee15]

11/10 =))

[@gami29rus]

Чаще бы такие ролики попадались тебе)! Гляди и гайды вернуться)

[@fed1splay]

Тебе лишь бы что-то, что будет пукан мне подпаливать 😂

[@borismirzakhanyan3545]

Нужно самим делать кринжовые ролики, чтобы они попадались fed1splay и он не забрасывал канал

[@gami29rus]

@@fed1splay зато какой шикарный ролик вышел)

[@listopadovsergey8008]

за Абсракцию!

[@inreck]

Genius...