@@djojbbhf Да, я строю новый завод, который покрывает объемы производства старого, стопаю старое производство, сношу старое производство. В программировании точно так же: есть хреново спроектированая подститсема, но на момент создания она устраивала. Проектируется новая, имплементируется, возможно часть функционала переводится, бывает параллельно работают обе... в конце концов переводится вся работа приложения на новую подсистему, выпиливается старая.
Чётко, понятно, но только для тех, кто в теме. Проще надо быть, и люди к тебе потянутся. Например начать играть и создавать базу параллельно комментируя основы программирования.
Во во, получеться что "объект" отвечает не только за работу с "данными", но и за их "парсинг", чем нарушает принцып Singe responsibility. Сити блоки куда ближе по сути к архитектуре програмирования
Принуждение не приведет ни к чему хорошему, можно сделать добровольные уроки в замен пению, физре, изо или другому второстепенному что бы просто попробовали и если понравится - учились, не понравилось - не учились, главное что бы измененная программа не добавляла и не убавляла часов, что бы не абъюзить систему
в факторио можно много разных концепций моделировать, но это не значит, что нужно их из одной сферы в другую тащить, это просто наглядное пособие, но никто так строить производство не будет в игре, это не эффективно
а можно играть на "микросервисной архитектуре", на так назывемых сити блоках. каждый ситиблок это территория, огражденная железной дорогой, например квадратики 100 на 100 рельм. на такой ситиблок можно завохить ресурсы и забирать. каждый ситиблок отвечает за создание конкретного ресурса. например плавильный ситиблок, или ситиблок создающий все предсеты в игре, необходимые для строителства других ситиблоков, так называемый дрон молл. можно создать чертежи под каждый ситиблок и ресурс в игре, а также чертеж самого ситиблока, который имеет относительную привязку, благодаря чему можно не отпуская мышку поставить 100 ситиблоков на чертеж. по границе ситиблока и внутри можно установить дрон станции, за счет чего дроны будут брать рельсы и все прочие ресурсы из молл ситиблока и строить ваши ситиблоки, а вам останется лишь разрабатывать залжеи ресурсов, обеспичвать базу энергией(если строить сити блок на воде, то в один ситиблок влезет 4 реактора, суммарной мощностью 4.4 гвт, что при большом обьеме производства не так и много)
Этой архитектуре отлично подходит мод LTN - Logistic Train Network. Этот мод вводит дополнительную логику для поездов, которая позволяет им ездить из депо, куда угодно, чтобы забирать или отвозить ресурсы кому нужно. Станции в таком случае делятся на 2 типа: Provider - станция поставщик ресурсов из подключенного хранилища и Requester - станция, запрашиватель ресурсов из Prodiver станций.
Так и делал, в принципе рабочая схема, но масштабируется тяжело. Будущее за суперблоком - ситиблок, который на вход принимает 5 базовых ресурсов (4 руды и нефть), производит всю науку одновременно и всю ее перерабатывает. Далее просто копипастим суперблок столько сколько науки хотим (вытягивает процессор), нарасчиваем добычу, вытесняем кусак. Сюда нужна обслуживающая инфраструктура (электроэнергетика, заправка поездов, молл) - ее можно оставить на ситиблоках. Правда играть становится не интересно.
@@user-ch76tcye4vvuu8 вот да, не интересно играть это точно подмечено. самый большой рост заводчанина это приход понимания что спагетти весело до поры до времени, потом тебя это начинает бесить и тебя осеняет что можно производить все по отдельности и выводить на общую шину. после ты переходишь на полный формат базы на шине, дальше на ситиблоки и тд и понимаешь "ах, какое же спагетти вкусное было" и возвращаешься к началу начал :)
У этой схемы эффективность стремится к нулю. Производство "по месту" - не очень, так как мы, строим лишние заводы, что эквивалентно повторному коду. Для избежания таких повторений в языках придумали - функции, а в факторке - "цеха" (Просто массив заводов, которые будут обеспечивать всю фабрику, делая её более "читабельной" и менее "мокоронной". И при всём при этом, если массив достаточно большой, уменьшает время ожидания изготовления предмета
@@p.k.r.7963 Когда ты указываешь на неэффективные элементы и предлагаешь пути оптимизации, ты почти наверняка прав. А когда тестер говорит что оптимизация там не нужна, он точно не прав.
если функционал из заводика 1 нужно поменять, то придется не только пересобирать наследующиеся от 1го завода объекты: 2,3,4, но и предусмотреть ситуации в которых поведение 1го влияет на остальных
Я тоже, когда первый раз столкнулся с ооп и интерфейсами , проводил параллели между этими понятиями в программировании и функциональностью игры в которую я играл.
Благодаря этому ролику понимание ООП усложнилось в 50000 раз. В университете, давным давно, парадигма ООП гораздо проще объяснялась на примере игры в шахматы. Но автору надо отдать должное за оригинальный, не тривиальный, подход к раскрытию сути ООП. Лайк. С автором согласен, что в подавляющем большинстве мелких проектов не используется ООП.
Отличный мод. Очень удобно разделять производства по ангарам и потом соединять либо последовательно, либо параллельно, в зависимости от способа распределения производств.
Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма: 1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :) 2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.
за наглядную визуализацию через factorio конечно лайк, но есть пара замечаний: - завод все равно зависит от внешней среды, потому что нефть поставляется в бочках, а значит где-то за кадром есть автомат куда отвозят пустые бочки и отправляют полные. так что с инкапсуляцией тут беда. - вместо руд можно было бы сразу поставлять пластины, один хрен плавильни на базе должны быть. да и электросхемы нет смысла производить внутри этой системы. они производятся в отдельном блоке в больших кол-вах. также с нефтянкой. иначе получается дублирование производства. инкапсуляция в том, что для создания последующих модулей нужен предыдущий. можно было бы сделать один ситиблок, к нему подвести пластины, схемы, пластик, а дублировать бы пришлось только автоматы с модулями. - сбор модуля 1 - сбор модуля 1 + модуль 2 - модуль 2 + модуль 3 как должно быть проще для восприятия. нет нужды дублировать производство базовых ресурсов. да и полной автономии добиться нельзя, все равно где-то должен стоять генератор, ситиблоки для руд, мол и тд
на самом деле если вообще всю базу сделать из ситиблоков, то будет ооп. в каждом блоке свое производство, независимо от другого. наследование - когда для одного ситиблока требуется ресурс из другого. пример: производство схем или банок. ну и сама база это объект
Если уж говорить об ООП применительно к играм, то обязательно нужно упомянуть Space Engineers. Это та игра, где C# можно изучить. Там все системы на иерархии различных интерфейсов построены. И заодно изучить векторную алгебру - там 3D пространство со всеми вытекающими: векторы, матрицы...
но ведь в примере в конце нарушен по сути базовый приинцип "Don't repeat yourself". причем настолько грубо, насколько это вообще возможно )) а так игра великолепна )
Это скорее пример композиции, нежели наследования. Если завод модуля скорости 2 наследует завод модуля скорости 1, то он может производить на выход модуль скорости 1. Но это не так, он выдает модуль скорости 2!! Тут разве что один уровень наследования -- SpeedModule1Workshop: Workshop и SpeedModule2Workshop: Workshop, который переиспользует SpeedModule1Workshop, ну и т.д. для SpeedModule3Workshop.
Интересное наложение принципов программирования на игру. А использование шины конверов в игре - это что в програмировании, распараллеливание задач на потоки ? Имеется в виду что на шину выводятся промежуточные изделия.
Я эту логику понял ещё когда питоне в структурном стиле писал. Быстро становится тяжело, если функция делает много чего-то. Функции надо проектировать подобным же образом.
Только как бы то небыло, но в факторио выгоднее разносить производство по разным местам, в одном месте плавить железо, в другом медь, в другом нефть, так зачастую получаеися эффективние) (p.s. LTN сушествует)
Да-да-да. Всё как в жизни. Сделал один объект красивым, остальные идут в жертву. Например пластик. Копипаста такая линейных участков кода. Потом начинаешь вылизывать объект производства пластика, что-то третье идёт по швам. Третье переделал - другие два надо перепилить. Весь проект этим и занимаешься. Нужно правильно выбирать парадигму. Видел "шедевр" однажды как банковские процессы на ООП писали. Объект "кредит" у меня в мемах.
Если задача плохо решается в объектной парадигме - не надо руками и ногами запихивать в неё решение)) Да, в остальную систему всё-равно придётся наверняка встраивать в виде объекта, но никто не мешает внутри сделать так, как было бы удобнее.
Программистам везде мерещиться ООП. Даже в Factorio ООП не нужен так как завод показанный в видео чрезмерно много место занимает, а выхлоп - один заводик который долго производит карту. Как делают опытные игроки в Factorio: реализация через шину или сити-блоки на поездах. Принцип шины самый лучший. Идёт огромная шина из конвейеров. Мы стараемся делать такие блоки производства которые берут из шины по максимуму ресурсов и производят полный конвейер продукции, возвращая в шину результат. По сути реализация функционального программирования. И это работает в разы лучше так как конвейеры всегда заполнены по максимуму. Из минусов - ширина шины может быть большой. По этому для решения этой проблемы базу перестраивают под поезда и строят сити-блоки. Там уже другая проблема - размеры сити-блоков бывают огромны. Но зато расширять производство на них проще. Поезда сами куда нужно отвозят товар и сами забирают готовую продукцию. Принцип тот же, только на поездах.
Немножечко понимаю, что такое ООП. Немножечко пользуюсь. Но не владея контекстом игры от такой визуализации мне ничего понятнее не стало. Вернее, на словах концепцию и аналогию с игровым конвейером я понял, а иллюстрация какая-то не понятная. Я не понял, что она иллюстрирует.
На код ревью, бросаются в глаза дубликаты жестко кода. Один из сырых ресурсов и правда нужен. 12:50 Для описания абстракции необходимо сузить поле сущностей до функциональных (какая задача -> кто исполнитель -> как), ввести понятие 'ограничения' и разобрать исключения на примерах. Дурной тон - сравнение, декларация с подтверждением работоспособности.
спасибо за коммент, подумал, что это у меня лыжи не едут: печки и выплавка как будто нарушают принцип DRY, и кажется, что выплавленные плиты должны ехать как ресурс, прям на входе уже быть готовыми
При объяснении ООП всегда рассматривают 3 либо 4 принципа. Но почему-то мало где говорят, в чём вообще смысл слов "объектно-ориентированное", в чём выражается та самая "ориентированность на объекты". Есть ёмкая фраза насчёт этого, и насчёт инкапсуляции в частности. Звучит примерно так: "объединение данных и методов работы с ними". Т.е. всё, что можно делать с данными (методы, функции, операторы), описаны в одном месте (классе) с этими данными. Правда, как это переложить на Факторио -- не знаю :)
Честно говоря, я руду переплавляю в плиты прямо у месторождений. А на сборщики подаю плиты с поездов, через конвейеры. Иногда даже второй передел (плиты в проволоку) делаю у рудника, а поездами развожу. Но ролик всё равно хорош!
На моей мега-базе на 65 науки в секунду оно так работать не будет, там у меня рассчитано потребление всех типов базовой продукции (металлы, микросхемы, жидкости) всеми производствами, и они делаются в своих отдельных кластерах, медь и железо например делаются на своих гигантских плавильнях которые занимают несколько десятков экранов. Весь транспорт осуществляется по 4-х путевой ж/д. Это не ООП получается?
На практике вопрос архитектуры - трейд между целями и ресурсами. Если надо дешево и быстро, без потенциала в расширение, то зачем тратиться на что-то кроме функционального подхода ? Если нужно сделать часть проекта доступной для работы менее квалифицированного работника, зачем много уровней абстракций ? И тд.
Абстракцию нужно смотреть в современном психологическом справочнике. Каждый объект в современном мире мы рассматриваем как абстракцию, т.е. как множество отдельных свойств присущих объекту, которые можно рассматривать по отдельности, с не как какой-то несокрушимый монолит, это по сути и есть абстрактное мышление. Взять например наш любимый автомобиль каждый представит себе конкретный автомобиль, но в абстракции это транспортное средство которое содержит в себе некое бесконечное количество требований лиц которые его эксплуатируют, лиц которые на етом ездят, лиц которые это чинят, лиц которые это строят, лиц которые это разрабатывают, лиц которые... Думаю идею вы поняли и у каждой группы есть своя абстракция об этом объекте которая важная для одной группы и не очень важная для другойдругой и вроде можно рассматривать всё группы свойств объекта по отдельности, но успешным продуктом размышления будет "синергетический продукт" максимально удовлетворяющий всё группы, но при этом это не значит что ето будет удовлетворять всё группы по максимуму...
круто рассказал. Я, как начинающий, задам вопросик: и будет ли нормальным, когда в коде такого вот КЛАССА повторяются одни и те же функции (допустим функция из 20 строк, то есть 60 строк повторения - это норма?) или все же, мы юзаем одну и ту же функцию те же 3 раза, просто? Скорей всего никто об этом не думал, но в факторию есть что-то типа "пропускной способности" нашей функции, а в программировании, скорей всего нет. Спасибо за развернутый ответ
Сразу скажу, я не специалист и мое понимание далеко от практики, я сколько скриптов не писал - функция единственный понятный мне структурный элемент кода.
@@invisiblealex007Ну все от языка зависит, и от правильной структуры, но сам по себе вызов функции в нормальных языках не требует ресурсов, боле того, зачастую когда требуется массовое многократное действие разные экземпляры одной и той же функции можно выполнять в разных потоках, обеспечивая тем самым параллелизм и ускорение программы в целом
Я как истинный любитель натянуть сову на глобус и подумать о вечном, а также загрузить коллегу за чашкой смузи в офисе (которого у меня больше нет) провел не мало часов размышляя о том что же не так с ООП и как его исправить.. Я пришел к выводу, что концепция ООП не ложиться в концепцию вычислительных машин.. Ни один язык который я изучал в надежде найти тот самый ООП не дал ощущения работы с объектами.. Везде я работаю с алгоритмами и данными, а объекты эти ваши - прикол какой-то который все привыкли писать, а еще писать про них толстенные книги и рубить бабло на них) Мне кажется эта некая попытка стандартизировать программирование.. Якобы нарубал себе объектов как шестерен и работаешь с ними, собирая то ли часы то ли ракету, но только каждый объект сука личность и каждая запятая в нем важна.. Вот и получается, что всегда нужно лезть своими грязными ручонками в реализацию и крутить хвосты каждому объекту в индивидуальном порядке. В общем и целом мне кажется, чтобы построить коммуни... Извините... То есть что бы получить чистый ООП, ты как программист должен оперировать объектами.. Жонглировать ими, но никогда не залазить в их реализацию, что к сожалению не возможно на том уровне абстракции, где мы сейчас находимся.. Так что всем бобра.. ЗЫ: Я так и не пон, причем тут факторио к ООП... Объясните, люди добрые :)
Теория хороша. А теперь практика. Если объекты не зависимы то на входе подают чистые данные (руда, нефть). Получается чтобы сделать объект создающий белые колбы (ракета + спутник) Нужно много много повторений одного и того же (наследование) в виде сложного и большого дерева. А ведь на всё это нужны ресурсы и постойки. А на каждую постройку свой модуль, со своим сложным деревом, и это если энергия подводится, а если мы хотим свою собственную энергию в каждом модуле (независимость), то задача усложняется многократно. И как удобно: этим ещё никак управлять нельзя, а вопросы балансировки выхода/входа между модулями станет вашим ночным кошмаром, если конечно вы не хотите ждать вечнось до постройки объекта ракеты. А теперь вспомним, что это упрощённая аналогия (очень хорошая, я отмечу), и в ней не показано множество деталей.
Вот так объяснил) По традиции - переделывай ролик. Абстракция в игре - это в самом примитивном виде архитектурный подход к строительству фабрики. Макароны, шина, сити-блоки. Это примеры абстракции. Когда вся суть своидтся к моделированию сущностей и их взаимодействия. Сущности тут будут представлены как некие цеха или блоки цехов, а взаимодействие - система транспорта. Ленты, дроны, поезда. Инкапсуляция - это любой законченный цех, получающий на вход продукт X, выдающий продукцию Y. При этом взаимодействие с цехом идёт только через входные-выходные интерфейсы. Ленты, или жд станции, например. Или весь пример в ролике, производящий модули трёх типов из базового ресурса. Наследование можно рассмотреть с точки зрения композиции и агрегации. Пример композиции - это совокупность модуля и сборочного автомата. А агрегация - это совокупность манипулятора и сборочного автомата. Подобные конструкции применяются всегда и везде. Полиморфизм тоже можно рассмотреть с разных сторон. Ad-hoc представляется в виде совокупности сборочного автомата и разных рецептов в нём. Тут проволка, там шестерни. Параметрический полиморфизм - это в целом возможность менять рецепты внутри сборочников. Полиморфизм подтипов можно представить на уровне двух цехов, производящих железные пластины. Один цех производит на обычных печках, другой - на электропечах. Нельзя натянуть сову на глобус, не рассматривая сабж в комплексе.
Всё же проще в разы: У тебя есть объект, а объект это совокупность стейта\данных и методов\функций. Остальное про инкапсуляцию, и прочую композицию можно просто отбросить, ибо она и функциональной парадигме присуща в равной степени Если на примере факторио говорить: ООП это когда ты завод для железных плит, и всего с ними связанного, на железном руднике строишь прямо на месте. При этом, строишь аналогичный завод но уже на месте медного рудника, даже если заводы похожи как две капли воды. ФП же, в свою очередь, это когда ты строишь кучу мелких фабрик, и начинаешь дрочиться с логистикой ресурсов, делая при этом важное ебало, и яростно пытаешься убедить себя в неотвратимости и "единствоправельности" такого подхода. Короче, либо процедурка на контроллерах, либо AI no-code платформы для клепания крудов, остальное от лукавого! 🫠
полиморфизм - это не "выдача объектом всего функционала, что он умеет" полиморфизм - это единообразие обращения с объектами разного типа через один и тот же интерфейс, встроенный в них. механизмы предоставления такого интерфейса могут быть разными, но суть та же: обрабатывать разные объекты одним способом. иными словами, не переобучая рабочий узел работе с разными сущностями, всё-же, получать от него обработку широкого спектра этих сущностей, всего лишь внедрив в них одинаковый интерфейс обращения. так, в реальной жизни, человек может ухватиться за любой поручень или ручку. всё, к чему приделана "рукоятка" в форме изогнутой палки, подходит в качестве удобного интерфейса для руки - двери, рамы окон, поручни, перила, ручки сумок, прорези коробок, рукоятки ножей, оружия, джойстики, рычаги, рули управления транспортом, всё это - полиморфно обрабатываемые человеческой рукой, как универсальным хватателем, объекты. пример из области программирования - это возможность осуществить операцию сложения двух строк, либо двух чисел, либо чего-то ещё, для чего оперделена операция сложения, при помощи бинарного оператора "+". оператор один и тот же, а типы разные, как разнятся и результаты. но вот способ оперирования - один и тот же: два значения на входе и одно на выходе в качестве результата, что составляет интерфейс операции для полиморфной обработки. ну и конечно же, динамический/статический полиморфизм, предоставляемый механизмом наследования, либо реализации интерфейса (набора методов и/или свойств) и позволяющий получать полиморфность по наследству, любо по структурной схожести, предоставляя возможность для объектов реализовывать обращение к себе со стороны других объектов через хорошо известный интерфейс.
П офакторио понятно! А в программах что является обьектом ? Если я хочу написать программу которая к примеру удаляет файлы на диске в алфавитном порядке через 1 букву, что там будет обьектом ? Что классом ? Что будет наследованием, что инкапсуляцией ?
"Файл" будет классом, он будет предоставлен стандартной библиотекой любого вменяемого языка. У него можно получить имя вызовом чего-то типа getName (суть инкапсуляции в том, что этот getName именно часть самого класса, зашитая прямо в него, а не часть какого-то внешнего программного модуля, такой элемент класса называется его "методом"). В итоге у вас на руках имя. В качестве второго класса вы можете создать абстракцию вроде "FileLifeSolver", его предназначением будет просто решить судьбу любого объекта типа "файл", который ему будет предложен на рассмотрение, и его ответ будет "да" или "нет". Для этого вы создаете внутри солвера метод, например, mustBeDestroyed(name). Потом вы этот результат может скормить третьему классу, который, положим, будет называться FileDestroyer, и его задача будет убить любой файл, для которого вы получили на прошлом шаге "true" (да, следует уничтожить). На самом деле все гораздо сложнее в том, как эти объекты взаимодействуют, и что собой представляют, но в основе все примерно так. Непонимание на первом этапе знакомства с этими вещами связано с тем, что все пояснения сводятся ко всяким лающим собакам и нарыющим рыбам, и обучаемый входит в заблуждение что эти "объекты" действительно соответствуют объектам из физической реальности. На самом деле вообще не так. Объект в 95% случаев просто концентрирует в себе какую-то ограниченную функциональность предметной области. А вообще, замечание ваше верное - намного эффективнее будет почитать нормальный гайд по всем этим принципам, чем что-то понять по этому притянутому за уши сравнению в ролике. Например, при чем тут вообще полиморфизм - абсолютное хз. Полиморфизм это способность кода обрабатывать "разное схожим образом", и к тому же имеет свои подтипы. Например, очевидно, что упомянутое getName можно вызвать у всего, что вообще имеет имя, а не только у файла - это черты полиморфного поведения. При чем тут "выдача всего что умеет объект" наверное только автору известно.
@@ironoscar3948 Воистину, попытка впихнуть объектное решение в задачу, где нет объектов, выглядит весьма уродливо. Особенно вот эти вот классы на -er, которые по сути не являются объектами, а лишь объединяют в себе некоторый функционал. По сути, утилитные классы. Данная задача больше подходит для процедурного решения.
@@0imaxЯ именно поэтому там и отметил особо, что "на самом деле все сложнее в том как это взаимодействует и что собой представляет". Мне что, надо было там начать рассказывать что утильные классы не инстанциируют, а вызывают что-то прямо из них, и что результаты не "передаются между объектами" в буквальном понимании, а тупо одни вызовы тупо инлайнятся прямо внутрь других, и в итоге все расписанное это одна строчка кода (при условии что утильные классы уже готовы)? Это во-первых заняло бы еще большую стену текста, а во-вторых, тот кто это был бы способен понять, уж точно бы не стал задавать такие вопросы.
Это конечно здорово всё так изолировать, но вот производить зелёные платы и прочее внутри каждого завода нарушает принцип DRY. Эти "минизаводы зелёных плат" нужно будет постоянно копировать. В программировании это выглядело бы так: вместо добавления зависимости в класс (например через конструктор), мы бы писали/копировали реализацию этой зависимости внутри класса, и так каждый раз!. В итоге зависимости вроде бы нет и это здорово, но размер кода стал бы огромным!(Хотя в некоторых языках, можно инкюдить файлы прям в тело функции ; )).
мне интересно, как ты решишь проблему нехватки заводов при этом не нарушая этот принцип? Вообще мне кажется мы и в этом случаи не копируем реализацию в класс, это у нас уже идет ассоциация, или мы передаем коллекцию объектов(заводов) в другой объект. А классом тут выступает скорее чертеж
@@factorevo2006-sv2mmНу насчет чертеж - это класс я согласен. Но что если нам нужно будет обновить этот класс( например с красных конвееров перевести на синие для ускорения процесса). В программировании мы бы просто изменили бы один файл и всё. А здесь нам нужно будет бегать по всей карте и вручную выделять что обновить(благо есть удобный инструмент).
@@gecreator412 можно сделать поправку на то что факторио и программирование это разные вещи, хотя и твоё утверждение можно парировать тем, что например в существующем приложении ты так просто не изменишь класс, тем более если он тут уже долгое время и вросся в систему, тебе придется меня еще куеву тучу других классов зависящих от него, при этом если ты что-то забыл учесть, то гг. В факторио с этим конечно попроще. А если сити блоки делать, так вообще красотища, можно их менять как перчатки в случаи роста потребностей игрока
С ООП код становится проще?! Или наоборот сложнее? Код без ООП читать проще, чем с ООП, при условии, что его написали понятно. Код как с так и без ООП можно написать так, что в нём ничего будет не понятно, тут уж в зависимости от поставленной задачи: написать так, чтобы другим было понятно; или написать так, чтобы никто ничего не понял...
Угу, всё легко и красиво, пока не нужна ни скорость, ни производительность, ни эффективность по памяти. Настоящий разговор в Factorio начинается примерно с 1000 науки в минуту, или с ачивки построить ракету за 4 часа. До этого момента можно делать плюс минус что угодно.
в контексте факторио, абстракция - это готовый блюпринт/чертеж/даже призрак при копировании будет абстракцией. Завод еще ничего не производит, ничего не потребляет, он может быть даже не построен, но уже размечен для последующей реализации, это позволяет уже планировать дальнейшее производство. Главный Нулевой принцип ООП: ООП для программистов, не для машины, машина под капотом все равно работает по императивной парадигме.
ну как посмотреть) атомарности тут чот нет, один класс все 3 модуля (по сути 3 объекта 3 разных классов) пилит интерфейс раздут масштабировать как? да и на dry положено. тут же явно базовый класс не расширяется наследованием а копирует кусок кода (плавильни например)
Ну это какое-то очень далекое описание. Почему бы просто не сформулировать что основа ООП это по сути группировка вложенных сущностей по функционалу, где более высокий уровень содержит общие черты присущие большинству низкоуровневых, а на низких уровнях соответственно растет специализация.
Вся суть ООП в том, что вы пишите код, который работает с абстракциями, а не напрямую с данными. Классы это шаблоны объектов, поэтому вы можете указать, что вы передаёте не некий объект, а объект соответствующий определённому шаблону. Ну и нужно понимать, что приложение это уже объект и невозможно написать программу, которая бы полностью была написана на ООП, всегда будет какаято часть императивного кожа, включая программные объекты. Завод в факторио никак не объясняет ООП, это просто работающая программа, каждый заводик это объект, а абстракции автор предлагает держать в голове, ну это не ООП подход.
Главный враг и спутник любого факториста - "пока так, потом перестрою"
А потом лень, я лучше новое добавлю рядом а старое будет стоять
В программировании также если что =)
@@djojbbhf Да, я строю новый завод, который покрывает объемы производства старого, стопаю старое производство, сношу старое производство.
В программировании точно так же: есть хреново спроектированая подститсема, но на момент создания она устраивала. Проектируется новая, имплементируется, возможно часть функционала переводится, бывает параллельно работают обе... в конце концов переводится вся работа приложения на новую подсистему, выпиливается старая.
Нет ничего постояннее, чем временное)))
И программиста....
Чётко, понятно, но только для тех, кто в теме. Проще надо быть, и люди к тебе потянутся. Например начать играть и создавать базу параллельно комментируя основы программирования.
Я: наблюдаю, как для производства модулей к заводам поступает руда вместо готовых плит.
Мой глаз: **дергается как тварь**
Во во, получеться что "объект" отвечает не только за работу с "данными", но и за их "парсинг", чем нарушает принцып Singe responsibility. Сити блоки куда ближе по сути к архитектуре програмирования
Спасибо🤝
Пожалуй вы 1 человек в ютьюбе кто рассказал об ООП понятно. Как говорится кто ясно мыслит тот ясно говорит.
После такого пояснения появляется желание ввести игру factorio в образовательную программу.
Никто из опытных игроков так не строит базу. Это очень не эффективно, только один сборщик который долго производит одно улучшение.
Множество раз слышал о таких идеях
Принуждение не приведет ни к чему хорошему, можно сделать добровольные уроки в замен пению, физре, изо или другому второстепенному что бы просто попробовали и если понравится - учились, не понравилось - не учились, главное что бы измененная программа не добавляла и не убавляла часов, что бы не абъюзить систему
@@Spectre4490политические уроки каждый год добавляют новые и не задумываются об этом)))
в факторио можно много разных концепций моделировать, но это не значит, что нужно их из одной сферы в другую тащить, это просто наглядное пособие, но никто так строить производство не будет в игре, это не эффективно
а можно играть на "микросервисной архитектуре", на так назывемых сити блоках. каждый ситиблок это территория, огражденная железной дорогой, например квадратики 100 на 100 рельм. на такой ситиблок можно завохить ресурсы и забирать. каждый ситиблок отвечает за создание конкретного ресурса. например плавильный ситиблок, или ситиблок создающий все предсеты в игре, необходимые для строителства других ситиблоков, так называемый дрон молл. можно создать чертежи под каждый ситиблок и ресурс в игре, а также чертеж самого ситиблока, который имеет относительную привязку, благодаря чему можно не отпуская мышку поставить 100 ситиблоков на чертеж. по границе ситиблока и внутри можно установить дрон станции, за счет чего дроны будут брать рельсы и все прочие ресурсы из молл ситиблока и строить ваши ситиблоки, а вам останется лишь разрабатывать залжеи ресурсов, обеспичвать базу энергией(если строить сити блок на воде, то в один ситиблок влезет 4 реактора, суммарной мощностью 4.4 гвт, что при большом обьеме производства не так и много)
Этой архитектуре отлично подходит мод LTN - Logistic Train Network. Этот мод вводит дополнительную логику для поездов, которая позволяет им ездить из депо, куда угодно, чтобы забирать или отвозить ресурсы кому нужно. Станции в таком случае делятся на 2 типа: Provider - станция поставщик ресурсов из подключенного хранилища и Requester - станция, запрашиватель ресурсов из Prodiver станций.
Ну ситиблоки - это и есть модули, созданные под конкретную задачу и отвечающие всем требованиям объектного проектирования
Так и делал, в принципе рабочая схема, но масштабируется тяжело. Будущее за суперблоком - ситиблок, который на вход принимает 5 базовых ресурсов (4 руды и нефть), производит всю науку одновременно и всю ее перерабатывает. Далее просто копипастим суперблок столько сколько науки хотим (вытягивает процессор), нарасчиваем добычу, вытесняем кусак. Сюда нужна обслуживающая инфраструктура (электроэнергетика, заправка поездов, молл) - ее можно оставить на ситиблоках.
Правда играть становится не интересно.
@@user-ch76tcye4vvuu8 вот да, не интересно играть это точно подмечено. самый большой рост заводчанина это приход понимания что спагетти весело до поры до времени, потом тебя это начинает бесить и тебя осеняет что можно производить все по отдельности и выводить на общую шину. после ты переходишь на полный формат базы на шине, дальше на ситиблоки и тд и понимаешь "ах, какое же спагетти вкусное было" и возвращаешься к началу начал :)
Как ни странно, но объяснение из вики о том, что "всё должно быть на объектах" гораздо точнее описывает суть ооп чем остальные 99% этого ролика.
а как может быть код не в обьектах ? ))
@@Bionic_Budda в функциях.
@@uuuummm9 без обьектов тебе нечего функциями обрабатывать
@@Bionic_Budda структуры данных.
@@uuuummm9 это уже структуры обьектов. ))
Теперь паттерны в программировании через factorio
на Хабре видел кстати статью о реализации архитектурных паттернов на factorio, оттуда и узнал про игру
Очень интересный и понятный ролик. Круто)
Требую продолжения :) Продолжай в том же духе . Когда ждать продолжения ?????
Блин, даже за 2 года всего 676подписчиков, у тебя отличный контент, желаю дальнейшего развития канала и продвижения контента ютубом.
У этой схемы эффективность стремится к нулю. Производство "по месту" - не очень, так как мы, строим лишние заводы, что эквивалентно повторному коду. Для избежания таких повторений в языках придумали - функции, а в факторке - "цеха" (Просто массив заводов, которые будут обеспечивать всю фабрику, делая её более "читабельной" и менее "мокоронной". И при всём при этом, если массив достаточно большой, уменьшает время ожидания изготовления предмета
Продолжи аналоги, если дроны это аякс, а руда это sql, то его функционал ляжет от 10 посетителей.
Иди учи мат часть ооп, ты не прав!
@@TestTest-cr2xb И в чём же?
@@p.k.r.7963 Когда ты указываешь на неэффективные элементы и предлагаешь пути оптимизации, ты почти наверняка прав. А когда тестер говорит что оптимизация там не нужна, он точно не прав.
Чел тут он наглядно показывает как ооп работает, он ресурс дронами привозит 🤷♂️ о чем речь тут все для наглядности а не для эффективности
Пожалуй худшее объяснение ооп которое мне попадалось)
Отличный пример, спасибо!
Факторио гениальная игра
если функционал из заводика 1 нужно поменять, то придется не только пересобирать наследующиеся от 1го завода объекты: 2,3,4, но и предусмотреть ситуации в которых поведение 1го влияет на остальных
Только через добавление, расширение, добавится абстракция.
В топы!
Спасибо за новое(!), довольно простое обьяснение ооп.
Спасибо за ролик! Отличный пример. Очень ценны комментарии. Подписался.
Я тоже, когда первый раз столкнулся с ооп и интерфейсами , проводил параллели между этими понятиями в программировании и функциональностью игры в которую я играл.
Спасибо. Очень классное видео, ничего не понял, зато кайфанул от просмотра как работает заводик
Это безумно хорошо и наглядно. Даже мотивирует писать именно так.
Очень круто спасибо
Ждём следующих роликов.
В топ!
Афигенная аналогия. Теперья захотел поиграть в факторио. Главное не залипнуть там на всегда ))
Подписался.
Благодаря этому ролику понимание ООП усложнилось в 50000 раз. В университете, давным давно, парадигма ООП гораздо проще объяснялась на примере игры в шахматы. Но автору надо отдать должное за оригинальный, не тривиальный, подход к раскрытию сути ООП. Лайк.
С автором согласен, что в подавляющем большинстве мелких проектов не используется ООП.
Приветствую! Не могли бы Вы Пересказать хотя бы вкрадце это объяснение на примере шахмат? Было бы интересно узнать
тоже интересно что за объяснение на шахматах
5:00 интересная мысль, спасибо.
Весь ролик ждал как раз примеры. Мой гуманитарный мозг агрессивно пытается думать. Ничего не понял но было очень интересно. Спасибо
Хорошо объяснил . Мне твой подход понравился . ( Я больше не теоретик ,а практик и ничего не понимаю в компьютерном программировании.)
Факториссимо идиально подходит для групировки опереденного дейсвия (в одном заводе мы делаем метал в другом электронику и так далее)
Респект за видео)
Отличный мод. Очень удобно разделять производства по ангарам и потом соединять либо последовательно, либо параллельно, в зависимости от способа распределения производств.
Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма:
1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :)
2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.
за наглядную визуализацию через factorio конечно лайк, но есть пара замечаний:
- завод все равно зависит от внешней среды, потому что нефть поставляется в бочках, а значит где-то за кадром есть автомат куда отвозят пустые бочки и отправляют полные. так что с инкапсуляцией тут беда.
- вместо руд можно было бы сразу поставлять пластины, один хрен плавильни на базе должны быть. да и электросхемы нет смысла производить внутри этой системы. они производятся в отдельном блоке в больших кол-вах. также с нефтянкой. иначе получается дублирование производства. инкапсуляция в том, что для создания последующих модулей нужен предыдущий.
можно было бы сделать один ситиблок, к нему подвести пластины, схемы, пластик, а дублировать бы пришлось только автоматы с модулями.
- сбор модуля 1
- сбор модуля 1 + модуль 2
- модуль 2 + модуль 3
как должно быть проще для восприятия. нет нужды дублировать производство базовых ресурсов. да и полной автономии добиться нельзя, все равно где-то должен стоять генератор, ситиблоки для руд, мол и тд
Хороший ответ, наглядно ООП рассыпалась
на самом деле если вообще всю базу сделать из ситиблоков, то будет ооп. в каждом блоке свое производство, независимо от другого. наследование - когда для одного ситиблока требуется ресурс из другого. пример: производство схем или банок. ну и сама база это объект
Маленькая ирония в том, что факторио написан с помощью подхода, ориентированного на данные, а не объекты.
@magla не могли бы вы дать ссылку на ваш публичный репозиторий? ищу примеры хорошей реализации ооп практик. заранее спасибо
Пхапхааа
Жду нового урока
Занятно
Проблема в балансировке. Где то 2 завода овермного, где то нужно 20 ставить чтобы спрос удовлетворить, отсюда вермишель
Ну так там есть цифры соотношения сам считай
Комментарии спасают ролик
Если уж говорить об ООП применительно к играм, то обязательно нужно упомянуть Space Engineers. Это та игра, где C# можно изучить. Там все системы на иерархии различных интерфейсов построены. И заодно изучить векторную алгебру - там 3D пространство со всеми вытекающими: векторы, матрицы...
но ведь в примере в конце нарушен по сути базовый приинцип "Don't repeat yourself". причем настолько грубо, насколько это вообще возможно ))
а так игра великолепна )
Факторка скорее процессор чем код.
Схема в конце по-моему великовата, наверное это всё можно было бы ужать
Видны простои ресурсов, например медной проволоки, потому что не учтены соотношения. По наглядности все отлично, по эффективности не очень.
Это скорее пример композиции, нежели наследования. Если завод модуля скорости 2 наследует завод модуля скорости 1, то он может производить на выход модуль скорости 1. Но это не так, он выдает модуль скорости 2!! Тут разве что один уровень наследования -- SpeedModule1Workshop: Workshop и SpeedModule2Workshop: Workshop, который переиспользует SpeedModule1Workshop, ну и т.д. для SpeedModule3Workshop.
Видео отлично, но нужно поработать над подачей информации. Сильно затягиваете
Провода огонь!
Охренеть! Выбритый программист!
Интересное наложение принципов программирования на игру. А использование шины конверов в игре - это что в програмировании, распараллеливание задач на потоки ? Имеется в виду что на шину выводятся промежуточные изделия.
Паттерн шина данных, ахахахаха
@@Lifesplay Ситиблоки лучше
Я эту логику понял ещё когда питоне в структурном стиле писал. Быстро становится тяжело, если функция делает много чего-то. Функции надо проектировать подобным же образом.
Только как бы то небыло, но в факторио выгоднее разносить производство по разным местам, в одном месте плавить железо, в другом медь, в другом нефть, так зачастую получаеися эффективние) (p.s. LTN сушествует)
Да-да-да. Всё как в жизни. Сделал один объект красивым, остальные идут в жертву. Например пластик. Копипаста такая линейных участков кода. Потом начинаешь вылизывать объект производства пластика, что-то третье идёт по швам. Третье переделал - другие два надо перепилить. Весь проект этим и занимаешься. Нужно правильно выбирать парадигму. Видел "шедевр" однажды как банковские процессы на ООП писали. Объект "кредит" у меня в мемах.
гыгы
Если задача плохо решается в объектной парадигме - не надо руками и ногами запихивать в неё решение))
Да, в остальную систему всё-равно придётся наверняка встраивать в виде объекта, но никто не мешает внутри сделать так, как было бы удобнее.
Это должны знать все, должны понимать все, не должен использовать никто.
Программистам везде мерещиться ООП. Даже в Factorio ООП не нужен так как завод показанный в видео чрезмерно много место занимает, а выхлоп - один заводик который долго производит карту.
Как делают опытные игроки в Factorio: реализация через шину или сити-блоки на поездах.
Принцип шины самый лучший. Идёт огромная шина из конвейеров. Мы стараемся делать такие блоки производства которые берут из шины по максимуму ресурсов и производят полный конвейер продукции, возвращая в шину результат. По сути реализация функционального программирования. И это работает в разы лучше так как конвейеры всегда заполнены по максимуму.
Из минусов - ширина шины может быть большой. По этому для решения этой проблемы базу перестраивают под поезда и строят сити-блоки.
Там уже другая проблема - размеры сити-блоков бывают огромны. Но зато расширять производство на них проще. Поезда сами куда нужно отвозят товар и сами забирают готовую продукцию. Принцип тот же, только на поездах.
Немножечко понимаю, что такое ООП. Немножечко пользуюсь. Но не владея контекстом игры от такой визуализации мне ничего понятнее не стало. Вернее, на словах концепцию и аналогию с игровым конвейером я понял, а иллюстрация какая-то не понятная. Я не понял, что она иллюстрирует.
На код ревью, бросаются в глаза дубликаты жестко кода. Один из сырых ресурсов и правда нужен. 12:50 Для описания абстракции необходимо сузить поле сущностей до функциональных (какая задача -> кто исполнитель -> как), ввести понятие 'ограничения' и разобрать исключения на примерах. Дурной тон - сравнение, декларация с подтверждением работоспособности.
спасибо за коммент, подумал, что это у меня лыжи не едут: печки и выплавка как будто нарушают принцип DRY, и кажется, что выплавленные плиты должны ехать как ресурс, прям на входе уже быть готовыми
@@AG-mt2rsте же мысли. А заодно нарушение принципов Солид.
По сути есть класс плавильня, есть классы зеленые микросхемы, красные, синие…
А полиморфизм, это когда ваську сводили к ветеринару )))
При объяснении ООП всегда рассматривают 3 либо 4 принципа. Но почему-то мало где говорят, в чём вообще смысл слов "объектно-ориентированное", в чём выражается та самая "ориентированность на объекты". Есть ёмкая фраза насчёт этого, и насчёт инкапсуляции в частности. Звучит примерно так: "объединение данных и методов работы с ними". Т.е. всё, что можно делать с данными (методы, функции, операторы), описаны в одном месте (классе) с этими данными.
Правда, как это переложить на Факторио -- не знаю :)
Честно говоря, я руду переплавляю в плиты прямо у месторождений. А на сборщики подаю плиты с поездов, через конвейеры. Иногда даже второй передел (плиты в проволоку) делаю у рудника, а поездами развожу.
Но ролик всё равно хорош!
На моей мега-базе на 65 науки в секунду оно так работать не будет, там у меня рассчитано потребление всех типов базовой продукции (металлы, микросхемы, жидкости) всеми производствами, и они делаются в своих отдельных кластерах, медь и железо например делаются на своих гигантских плавильнях которые занимают несколько десятков экранов. Весь транспорт осуществляется по 4-х путевой ж/д. Это не ООП получается?
А это уже ООП + SOLID
На практике вопрос архитектуры - трейд между целями и ресурсами.
Если надо дешево и быстро, без потенциала в расширение, то зачем тратиться на что-то кроме функционального подхода ?
Если нужно сделать часть проекта доступной для работы менее квалифицированного работника, зачем много уровней абстракций ?
И тд.
9:30 Но так же можно сказать про функциональщину и чистые функции, кек.
Абстракцию нужно смотреть в современном психологическом справочнике. Каждый объект в современном мире мы рассматриваем как абстракцию, т.е. как множество отдельных свойств присущих объекту, которые можно рассматривать по отдельности, с не как какой-то несокрушимый монолит, это по сути и есть абстрактное мышление. Взять например наш любимый автомобиль каждый представит себе конкретный автомобиль, но в абстракции это транспортное средство которое содержит в себе некое бесконечное количество требований лиц которые его эксплуатируют, лиц которые на етом ездят, лиц которые это чинят, лиц которые это строят, лиц которые это разрабатывают, лиц которые... Думаю идею вы поняли и у каждой группы есть своя абстракция об этом объекте которая важная для одной группы и не очень важная для другойдругой и вроде можно рассматривать всё группы свойств объекта по отдельности, но успешным продуктом размышления будет "синергетический продукт" максимально удовлетворяющий всё группы, но при этом это не значит что ето будет удовлетворять всё группы по максимуму...
Расскажи про биткоин!!!
Зачем
круто рассказал. Я, как начинающий, задам вопросик: и будет ли нормальным, когда в коде такого вот КЛАССА повторяются одни и те же функции (допустим функция из 20 строк, то есть 60 строк повторения - это норма?) или все же, мы юзаем одну и ту же функцию те же 3 раза, просто? Скорей всего никто об этом не думал, но в факторию есть что-то типа "пропускной способности" нашей функции, а в программировании, скорей всего нет. Спасибо за развернутый ответ
Вообще, наследование и полиморфизм это как раз для избежания повторного написания кода. Не вполне возможно воспроизвести все это в факторио.
Сразу скажу, я не специалист и мое понимание далеко от практики, я сколько скриптов не писал - функция единственный понятный мне структурный элемент кода.
@@dreykzero2549 то есть функцию можно юзать (и нужно ) многократно и это не будет бутылочным горлышком?
@@invisiblealex007Ну все от языка зависит, и от правильной структуры, но сам по себе вызов функции в нормальных языках не требует ресурсов, боле того, зачастую когда требуется массовое многократное действие разные экземпляры одной и той же функции можно выполнять в разных потоках, обеспечивая тем самым параллелизм
и ускорение программы в целом
Я как истинный любитель натянуть сову на глобус и подумать о вечном, а также загрузить коллегу за чашкой смузи в офисе (которого у меня больше нет) провел не мало часов размышляя о том что же не так с ООП и как его исправить.. Я пришел к выводу, что концепция ООП не ложиться в концепцию вычислительных машин.. Ни один язык который я изучал в надежде найти тот самый ООП не дал ощущения работы с объектами.. Везде я работаю с алгоритмами и данными, а объекты эти ваши - прикол какой-то который все привыкли писать, а еще писать про них толстенные книги и рубить бабло на них)
Мне кажется эта некая попытка стандартизировать программирование.. Якобы нарубал себе объектов как шестерен и работаешь с ними, собирая то ли часы то ли ракету, но только каждый объект сука личность и каждая запятая в нем важна.. Вот и получается, что всегда нужно лезть своими грязными ручонками в реализацию и крутить хвосты каждому объекту в индивидуальном порядке.
В общем и целом мне кажется, чтобы построить коммуни... Извините... То есть что бы получить чистый ООП, ты как программист должен оперировать объектами.. Жонглировать ими, но никогда не залазить в их реализацию, что к сожалению не возможно на том уровне абстракции, где мы сейчас находимся..
Так что всем бобра..
ЗЫ: Я так и не пон, причем тут факторио к ООП... Объясните, люди добрые :)
прикол в том, что ты и описал. просто визуально показал чел, что делаются "кубики", из которых потом что-то мастерится
Теория хороша. А теперь практика.
Если объекты не зависимы то на входе подают чистые данные (руда, нефть). Получается чтобы сделать объект создающий белые колбы (ракета + спутник)
Нужно много много повторений одного и того же (наследование) в виде сложного и большого дерева.
А ведь на всё это нужны ресурсы и постойки. А на каждую постройку свой модуль, со своим сложным деревом, и это если энергия подводится, а если мы хотим свою собственную энергию в каждом модуле (независимость), то задача усложняется многократно.
И как удобно: этим ещё никак управлять нельзя, а вопросы балансировки выхода/входа между модулями станет вашим ночным кошмаром, если конечно вы не хотите ждать вечнось до постройки объекта ракеты.
А теперь вспомним, что это упрощённая аналогия (очень хорошая, я отмечу), и в ней не показано множество деталей.
Неплохо, игра заиграла новыми красками)
Можно еще EventBus построить на примере поездов 😁
Вот так объяснил) По традиции - переделывай ролик.
Абстракция в игре - это в самом примитивном виде архитектурный подход к строительству фабрики. Макароны, шина, сити-блоки. Это примеры абстракции. Когда вся суть своидтся к моделированию сущностей и их взаимодействия. Сущности тут будут представлены как некие цеха или блоки цехов, а взаимодействие - система транспорта. Ленты, дроны, поезда.
Инкапсуляция - это любой законченный цех, получающий на вход продукт X, выдающий продукцию Y. При этом взаимодействие с цехом идёт только через входные-выходные интерфейсы. Ленты, или жд станции, например. Или весь пример в ролике, производящий модули трёх типов из базового ресурса.
Наследование можно рассмотреть с точки зрения композиции и агрегации. Пример композиции - это совокупность модуля и сборочного автомата. А агрегация - это совокупность манипулятора и сборочного автомата. Подобные конструкции применяются всегда и везде.
Полиморфизм тоже можно рассмотреть с разных сторон.
Ad-hoc представляется в виде совокупности сборочного автомата и разных рецептов в нём. Тут проволка, там шестерни. Параметрический полиморфизм - это в целом возможность менять рецепты внутри сборочников. Полиморфизм подтипов можно представить на уровне двух цехов, производящих железные пластины. Один цех производит на обычных печках, другой - на электропечах.
Нельзя натянуть сову на глобус, не рассматривая сабж в комплексе.
У него там провода по стене кинуты. Это он автоматику подводил от комбинаторов?
Скорее всего акустика
Мда, Федор объяснил конечно намного лучше, нагляднее, но что главное более подробно из без воды на пол ролика
Объяснил, как боженька: нихуя непонятно, но этому надо следовать.
коэффициенты в механизмах не те
но видео неплохое
Чувак ты в корне не понял ООП =)
ну напиши как ты понял а то складывается впечатление что ты сам не знаешь
@@plohuena69 давайте для начала начмнем с концеции: "Класс" объекта и "Инстанс" объекта.
И ?@@unlike777
@@user-ge1fh8xl2v если у тебя возникает вопрос, то к сожалению ты тоже не понимаешь смысла
А что вам мешает записать свое видео на ютубе и обьяснить свою версию понимания ООП?
Функциональный стиль программирования?
Всё же проще в разы: У тебя есть объект, а объект это совокупность стейта\данных и методов\функций. Остальное про инкапсуляцию, и прочую композицию можно просто отбросить, ибо она и функциональной парадигме присуща в равной степени
Если на примере факторио говорить: ООП это когда ты завод для железных плит, и всего с ними связанного, на железном руднике строишь прямо на месте. При этом, строишь аналогичный завод но уже на месте медного рудника, даже если заводы похожи как две капли воды.
ФП же, в свою очередь, это когда ты строишь кучу мелких фабрик, и начинаешь дрочиться с логистикой ресурсов, делая при этом важное ебало, и яростно пытаешься убедить себя в неотвратимости и "единствоправельности" такого подхода.
Короче, либо процедурка на контроллерах, либо AI no-code платформы для клепания крудов, остальное от лукавого! 🫠
Все ушли так и не дождавшись ни слова про факторио
полиморфизм - это не "выдача объектом всего функционала, что он умеет"
полиморфизм - это единообразие обращения с объектами разного типа через один и тот же интерфейс, встроенный в них. механизмы предоставления такого интерфейса могут быть разными, но суть та же: обрабатывать разные объекты одним способом. иными словами, не переобучая рабочий узел работе с разными сущностями, всё-же, получать от него обработку широкого спектра этих сущностей, всего лишь внедрив в них одинаковый интерфейс обращения. так, в реальной жизни, человек может ухватиться за любой поручень или ручку. всё, к чему приделана "рукоятка" в форме изогнутой палки, подходит в качестве удобного интерфейса для руки - двери, рамы окон, поручни, перила, ручки сумок, прорези коробок, рукоятки ножей, оружия, джойстики, рычаги, рули управления транспортом, всё это - полиморфно обрабатываемые человеческой рукой, как универсальным хватателем, объекты. пример из области программирования - это возможность осуществить операцию сложения двух строк, либо двух чисел, либо чего-то ещё, для чего оперделена операция сложения, при помощи бинарного оператора "+". оператор один и тот же, а типы разные, как разнятся и результаты. но вот способ оперирования - один и тот же: два значения на входе и одно на выходе в качестве результата, что составляет интерфейс операции для полиморфной обработки.
ну и конечно же, динамический/статический полиморфизм, предоставляемый механизмом наследования, либо реализации интерфейса (набора методов и/или свойств) и позволяющий получать полиморфность по наследству, любо по структурной схожести, предоставляя возможность для объектов реализовывать обращение к себе со стороны других объектов через хорошо известный интерфейс.
Вот уж не думал, что Курт Кобейн жив и поясняет за ООП....
Разбор сути этого видоса от Ляпина просто огонь "ёпта"
П офакторио понятно! А в программах что является обьектом ? Если я хочу написать программу которая к примеру удаляет файлы на диске в алфавитном порядке через 1 букву, что там будет обьектом ? Что классом ? Что будет наследованием, что инкапсуляцией ?
Для решения этой задачи лучше пользоваться функциональным программированием.
@@Silververt не надо усложнять. Обычная процедурная программа.
"Файл" будет классом, он будет предоставлен стандартной библиотекой любого вменяемого языка. У него можно получить имя вызовом чего-то типа getName (суть инкапсуляции в том, что этот getName именно часть самого класса, зашитая прямо в него, а не часть какого-то внешнего программного модуля, такой элемент класса называется его "методом"). В итоге у вас на руках имя. В качестве второго класса вы можете создать абстракцию вроде "FileLifeSolver", его предназначением будет просто решить судьбу любого объекта типа "файл", который ему будет предложен на рассмотрение, и его ответ будет "да" или "нет". Для этого вы создаете внутри солвера метод, например, mustBeDestroyed(name). Потом вы этот результат может скормить третьему классу, который, положим, будет называться FileDestroyer, и его задача будет убить любой файл, для которого вы получили на прошлом шаге "true" (да, следует уничтожить).
На самом деле все гораздо сложнее в том, как эти объекты взаимодействуют, и что собой представляют, но в основе все примерно так. Непонимание на первом этапе знакомства с этими вещами связано с тем, что все пояснения сводятся ко всяким лающим собакам и нарыющим рыбам, и обучаемый входит в заблуждение что эти "объекты" действительно соответствуют объектам из физической реальности. На самом деле вообще не так. Объект в 95% случаев просто концентрирует в себе какую-то ограниченную функциональность предметной области.
А вообще, замечание ваше верное - намного эффективнее будет почитать нормальный гайд по всем этим принципам, чем что-то понять по этому притянутому за уши сравнению в ролике. Например, при чем тут вообще полиморфизм - абсолютное хз. Полиморфизм это способность кода обрабатывать "разное схожим образом", и к тому же имеет свои подтипы. Например, очевидно, что упомянутое getName можно вызвать у всего, что вообще имеет имя, а не только у файла - это черты полиморфного поведения. При чем тут "выдача всего что умеет объект" наверное только автору известно.
@@ironoscar3948 Воистину, попытка впихнуть объектное решение в задачу, где нет объектов, выглядит весьма уродливо. Особенно вот эти вот классы на -er, которые по сути не являются объектами, а лишь объединяют в себе некоторый функционал. По сути, утилитные классы. Данная задача больше подходит для процедурного решения.
@@0imaxЯ именно поэтому там и отметил особо, что "на самом деле все сложнее в том как это взаимодействует и что собой представляет". Мне что, надо было там начать рассказывать что утильные классы не инстанциируют, а вызывают что-то прямо из них, и что результаты не "передаются между объектами" в буквальном понимании, а тупо одни вызовы тупо инлайнятся прямо внутрь других, и в итоге все расписанное это одна строчка кода (при условии что утильные классы уже готовы)? Это во-первых заняло бы еще большую стену текста, а во-вторых, тот кто это был бы способен понять, уж точно бы не стал задавать такие вопросы.
не очень понятен последний слайд - полиморфизм (объект выдает весь функционал, что умеет), не могли бы вы пояснить, спасибо
по сути это бред. полиморфизм это про разное исполнение одного действия в зависимости от типа исполняющего объекта
факторио топ!!!
Булджать, делай видос про пчел, хорош факторио гонять
Сам говорил объекты должны быть независимые, но заводик 2 наследует заводик 1. Интерфейсы..думаю там так.
Модульное программирование ?
Мэдскиллзовый вайринг на стене.
Это конечно здорово всё так изолировать, но вот производить зелёные платы и прочее внутри каждого завода нарушает принцип DRY. Эти "минизаводы зелёных плат" нужно будет постоянно копировать. В программировании это выглядело бы так: вместо добавления зависимости в класс (например через конструктор), мы бы писали/копировали реализацию этой зависимости внутри класса, и так каждый раз!. В итоге зависимости вроде бы нет и это здорово, но размер кода стал бы огромным!(Хотя в некоторых языках, можно инкюдить файлы прям в тело функции ; )).
мне интересно, как ты решишь проблему нехватки заводов при этом не нарушая этот принцип? Вообще мне кажется мы и в этом случаи не копируем реализацию в класс, это у нас уже идет ассоциация, или мы передаем коллекцию объектов(заводов) в другой объект. А классом тут выступает скорее чертеж
@@factorevo2006-sv2mmНу насчет чертеж - это класс я согласен. Но что если нам нужно будет обновить этот класс( например с красных конвееров перевести на синие для ускорения процесса). В программировании мы бы просто изменили бы один файл и всё. А здесь нам нужно будет бегать по всей карте и вручную выделять что обновить(благо есть удобный инструмент).
@@gecreator412 можно сделать поправку на то что факторио и программирование это разные вещи, хотя и твоё утверждение можно парировать тем, что например в существующем приложении ты так просто не изменишь класс, тем более если он тут уже долгое время и вросся в систему, тебе придется меня еще куеву тучу других классов зависящих от него, при этом если ты что-то забыл учесть, то гг. В факторио с этим конечно попроще. А если сити блоки делать, так вообще красотища, можно их менять как перчатки в случаи роста потребностей игрока
@@factorevo2006-sv2mmпоэтому и существуют интерфейсы, новую реализацию сделал и подключил.
В полный список идеального ООП входят 9 принципов, и даже не 4
С ООП код становится проще?! Или наоборот сложнее? Код без ООП читать проще, чем с ООП, при условии, что его написали понятно. Код как с так и без ООП можно написать так, что в нём ничего будет не понятно, тут уж в зависимости от поставленной задачи: написать так, чтобы другим было понятно; или написать так, чтобы никто ничего не понял...
Угу, всё легко и красиво, пока не нужна ни скорость, ни производительность, ни эффективность по памяти. Настоящий разговор в Factorio начинается примерно с 1000 науки в минуту, или с ачивки построить ракету за 4 часа. До этого момента можно делать плюс минус что угодно.
Я может процента три понял из этого видео. До смешного просто))))
Когда пишешь для себя точно с тебя спрашивают😂
То есть кот - это класс, а Васька - это объект этого класса.
Во всех книгах про ООП и С# отдельно отмечается. Первый принцип - абстракция.
в контексте факторио, абстракция - это готовый блюпринт/чертеж/даже призрак при копировании будет абстракцией. Завод еще ничего не производит, ничего не потребляет, он может быть даже не построен, но уже размечен для последующей реализации, это позволяет уже планировать дальнейшее производство. Главный Нулевой принцип ООП: ООП для программистов, не для машины, машина под капотом все равно работает по императивной парадигме.
Абстракцию прилепили к принципам ООП относительно недавно, и на мой взгляд - совершенно бессмысленно. Любой код - абстракция.
ну как посмотреть)
атомарности тут чот нет, один класс все 3 модуля (по сути 3 объекта 3 разных классов) пилит
интерфейс раздут
масштабировать как?
да и на dry положено. тут же явно базовый класс не расширяется наследованием а копирует кусок кода (плавильни например)
Жалко, что в наше время молодёжь совсем разучилась писать ООП
Ну это какое-то очень далекое описание. Почему бы просто не сформулировать что основа ООП это по сути группировка вложенных сущностей по функционалу, где более высокий уровень содержит общие черты присущие большинству низкоуровневых, а на низких уровнях соответственно растет специализация.
Почему бы не попить чай до записи ролика?
UPD: лучше ролик не записывать, если такие проблемы со знаниями в сфере/формулировкой мысли
Бывалые игроки, когда говорят что простое решение это ООП а не ситиблоки и поезда:
Вся суть ООП в том, что вы пишите код, который работает с абстракциями, а не напрямую с данными. Классы это шаблоны объектов, поэтому вы можете указать, что вы передаёте не некий объект, а объект соответствующий определённому шаблону. Ну и нужно понимать, что приложение это уже объект и невозможно написать программу, которая бы полностью была написана на ООП, всегда будет какаято часть императивного кожа, включая программные объекты. Завод в факторио никак не объясняет ООП, это просто работающая программа, каждый заводик это объект, а абстракции автор предлагает держать в голове, ну это не ООП подход.