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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это шедевр!

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

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

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

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

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

Зачетная травка попалась ))

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

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

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

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

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

ДОЖДАЛСЯ!!!

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

Отлично.

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

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

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

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

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

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

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

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

11/10 =))

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

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

Красавчик

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

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

У меня вопрос, перерыл весь инет, не нашел еормальной информации как установить чертежи с инета в факторио

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

🔥

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

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

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

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

Красава

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

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

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

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

Сижу на МКС. Вижу зарево, у кого-то полыхнуло, а потом перевожу взгляд, а там кто-то сову на глобус натягивает методом объекте ориентированного программирования. Мне даже и в голову не пришло, что эти два события связанны.

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

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

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

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

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

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

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

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

Блин, только сейчас увидел это видео) Тоже видел этого парня и решил сделать свое видео, но ты сделал это быстрее :((

Ребята а можно ссылку на ролик, от которого собственно пригорело?)

Ля, мне тоже ролик тот попался, но отложил. Так что пойду тоже "посижу" и посмотрю)

Сделай гайд по жд и LTN

Федя, что случилось? Чем-то другим занялся?

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

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

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

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

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

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

А где стрим чёрного экрана? Я чет найти не могу. Знаю, что Федя обещал. Не мог же он не выполнить обещание!

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

Лайк за Вована !

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

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

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

Что за гора хайпа в моей любимой игре про макароны

У понятиях, в нулевом элементе, ты написал "абсракция")))

Жду объяснение всего с++ на примере факторки за 2 часа от ждуна до сеньора

Уважаемый Федор, здравствуйте! Зачем при объяснении, сути полиморфизма, была вставлена картинка Владимира, да ещё в купе с фразой, "в общих чертах"? Я пока ржал, не понял сути полиморфизма. По крайней мере, не понял ваших объяснений! Шутка зачётная! Спасибо за толковый контент!

Ахаха тоже вчера попался этот ролик посмотрел послушал промотал ни х я не понял забил сегодня посмотрел тоже от нормального факторщика и сразу как все понял😂😂