@@djojbbhf Да, я строю новый завод, который покрывает объемы производства старого, стопаю старое производство, сношу старое производство. В программировании точно так же: есть хреново спроектированая подститсема, но на момент создания она устраивала. Проектируется новая, имплементируется, возможно часть функционала переводится, бывает параллельно работают обе... в конце концов переводится вся работа приложения на новую подсистему, выпиливается старая.
Полиморфизм вообще мимо, по-моему. Появился ролик, который чётко раскладывает принципы ООП по полочкам Факторио, насколько это возможно. "Парадигма ООП в Factorio, или как натянуть сову на глобус": ruclips.net/video/N8Q9TwwsVcI/видео.html Хотя и там я не со всем согласен.
Во во, получеться что "объект" отвечает не только за работу с "данными", но и за их "парсинг", чем нарушает принцып Singe responsibility. Сити блоки куда ближе по сути к архитектуре програмирования
Чётко, понятно, но только для тех, кто в теме. Проще надо быть, и люди к тебе потянутся. Например начать играть и создавать базу параллельно комментируя основы программирования.
Принуждение не приведет ни к чему хорошему, можно сделать добровольные уроки в замен пению, физре, изо или другому второстепенному что бы просто попробовали и если понравится - учились, не понравилось - не учились, главное что бы измененная программа не добавляла и не убавляла часов, что бы не абъюзить систему
в факторио можно много разных концепций моделировать, но это не значит, что нужно их из одной сферы в другую тащить, это просто наглядное пособие, но никто так строить производство не будет в игре, это не эффективно
а можно играть на "микросервисной архитектуре", на так назывемых сити блоках. каждый ситиблок это территория, огражденная железной дорогой, например квадратики 100 на 100 рельм. на такой ситиблок можно завохить ресурсы и забирать. каждый ситиблок отвечает за создание конкретного ресурса. например плавильный ситиблок, или ситиблок создающий все предсеты в игре, необходимые для строителства других ситиблоков, так называемый дрон молл. можно создать чертежи под каждый ситиблок и ресурс в игре, а также чертеж самого ситиблока, который имеет относительную привязку, благодаря чему можно не отпуская мышку поставить 100 ситиблоков на чертеж. по границе ситиблока и внутри можно установить дрон станции, за счет чего дроны будут брать рельсы и все прочие ресурсы из молл ситиблока и строить ваши ситиблоки, а вам останется лишь разрабатывать залжеи ресурсов, обеспичвать базу энергией(если строить сити блок на воде, то в один ситиблок влезет 4 реактора, суммарной мощностью 4.4 гвт, что при большом обьеме производства не так и много)
Этой архитектуре отлично подходит мод LTN - Logistic Train Network. Этот мод вводит дополнительную логику для поездов, которая позволяет им ездить из депо, куда угодно, чтобы забирать или отвозить ресурсы кому нужно. Станции в таком случае делятся на 2 типа: Provider - станция поставщик ресурсов из подключенного хранилища и Requester - станция, запрашиватель ресурсов из Prodiver станций.
Так и делал, в принципе рабочая схема, но масштабируется тяжело. Будущее за суперблоком - ситиблок, который на вход принимает 5 базовых ресурсов (4 руды и нефть), производит всю науку одновременно и всю ее перерабатывает. Далее просто копипастим суперблок столько сколько науки хотим (вытягивает процессор), нарасчиваем добычу, вытесняем кусак. Сюда нужна обслуживающая инфраструктура (электроэнергетика, заправка поездов, молл) - ее можно оставить на ситиблоках. Правда играть становится не интересно.
@@user-ch76tcye4vvuu8 вот да, не интересно играть это точно подмечено. самый большой рост заводчанина это приход понимания что спагетти весело до поры до времени, потом тебя это начинает бесить и тебя осеняет что можно производить все по отдельности и выводить на общую шину. после ты переходишь на полный формат базы на шине, дальше на ситиблоки и тд и понимаешь "ах, какое же спагетти вкусное было" и возвращаешься к началу начал :)
У этой схемы эффективность стремится к нулю. Производство "по месту" - не очень, так как мы, строим лишние заводы, что эквивалентно повторному коду. Для избежания таких повторений в языках придумали - функции, а в факторке - "цеха" (Просто массив заводов, которые будут обеспечивать всю фабрику, делая её более "читабельной" и менее "мокоронной". И при всём при этом, если массив достаточно большой, уменьшает время ожидания изготовления предмета
@@p.k.r.7963 Когда ты указываешь на неэффективные элементы и предлагаешь пути оптимизации, ты почти наверняка прав. А когда тестер говорит что оптимизация там не нужна, он точно не прав.
Я как истинный любитель натянуть сову на глобус и подумать о вечном, а также загрузить коллегу за чашкой смузи в офисе (которого у меня больше нет) провел не мало часов размышляя о том что же не так с ООП и как его исправить.. Я пришел к выводу, что концепция ООП не ложиться в концепцию вычислительных машин.. Ни один язык который я изучал в надежде найти тот самый ООП не дал ощущения работы с объектами.. Везде я работаю с алгоритмами и данными, а объекты эти ваши - прикол какой-то который все привыкли писать, а еще писать про них толстенные книги и рубить бабло на них) Мне кажется эта некая попытка стандартизировать программирование.. Якобы нарубал себе объектов как шестерен и работаешь с ними, собирая то ли часы то ли ракету, но только каждый объект сука личность и каждая запятая в нем важна.. Вот и получается, что всегда нужно лезть своими грязными ручонками в реализацию и крутить хвосты каждому объекту в индивидуальном порядке. В общем и целом мне кажется, чтобы построить коммуни... Извините... То есть что бы получить чистый ООП, ты как программист должен оперировать объектами.. Жонглировать ими, но никогда не залазить в их реализацию, что к сожалению не возможно на том уровне абстракции, где мы сейчас находимся.. Так что всем бобра.. ЗЫ: Я так и не пон, причем тут факторио к ООП... Объясните, люди добрые :)
Немножечко понимаю, что такое ООП. Немножечко пользуюсь. Но не владея контекстом игры от такой визуализации мне ничего понятнее не стало. Вернее, на словах концепцию и аналогию с игровым конвейером я понял, а иллюстрация какая-то не понятная. Я не понял, что она иллюстрирует.
Вот так объяснил) По традиции - переделывай ролик. Абстракция в игре - это в самом примитивном виде архитектурный подход к строительству фабрики. Макароны, шина, сити-блоки. Это примеры абстракции. Когда вся суть своидтся к моделированию сущностей и их взаимодействия. Сущности тут будут представлены как некие цеха или блоки цехов, а взаимодействие - система транспорта. Ленты, дроны, поезда. Инкапсуляция - это любой законченный цех, получающий на вход продукт X, выдающий продукцию Y. При этом взаимодействие с цехом идёт только через входные-выходные интерфейсы. Ленты, или жд станции, например. Или весь пример в ролике, производящий модули трёх типов из базового ресурса. Наследование можно рассмотреть с точки зрения композиции и агрегации. Пример композиции - это совокупность модуля и сборочного автомата. А агрегация - это совокупность манипулятора и сборочного автомата. Подобные конструкции применяются всегда и везде. Полиморфизм тоже можно рассмотреть с разных сторон. Ad-hoc представляется в виде совокупности сборочного автомата и разных рецептов в нём. Тут проволка, там шестерни. Параметрический полиморфизм - это в целом возможность менять рецепты внутри сборочников. Полиморфизм подтипов можно представить на уровне двух цехов, производящих железные пластины. Один цех производит на обычных печках, другой - на электропечах. Нельзя натянуть сову на глобус, не рассматривая сабж в комплексе.
Вся суть ООП в том, что вы пишите код, который работает с абстракциями, а не напрямую с данными. Классы это шаблоны объектов, поэтому вы можете указать, что вы передаёте не некий объект, а объект соответствующий определённому шаблону. Ну и нужно понимать, что приложение это уже объект и невозможно написать программу, которая бы полностью была написана на ООП, всегда будет какаято часть императивного кожа, включая программные объекты. Завод в факторио никак не объясняет ООП, это просто работающая программа, каждый заводик это объект, а абстракции автор предлагает держать в голове, ну это не ООП подход.
но ведь в примере в конце нарушен по сути базовый приинцип "Don't repeat yourself". причем настолько грубо, насколько это вообще возможно )) а так игра великолепна )
если функционал из заводика 1 нужно поменять, то придется не только пересобирать наследующиеся от 1го завода объекты: 2,3,4, но и предусмотреть ситуации в которых поведение 1го влияет на остальных
Ну это какое-то очень далекое описание. Почему бы просто не сформулировать что основа ООП это по сути группировка вложенных сущностей по функционалу, где более высокий уровень содержит общие черты присущие большинству низкоуровневых, а на низких уровнях соответственно растет специализация.
Благодаря этому ролику понимание ООП усложнилось в 50000 раз. В университете, давным давно, парадигма ООП гораздо проще объяснялась на примере игры в шахматы. Но автору надо отдать должное за оригинальный, не тривиальный, подход к раскрытию сути ООП. Лайк. С автором согласен, что в подавляющем большинстве мелких проектов не используется ООП.
Это скорее пример композиции, нежели наследования. Если завод модуля скорости 2 наследует завод модуля скорости 1, то он может производить на выход модуль скорости 1. Но это не так, он выдает модуль скорости 2!! Тут разве что один уровень наследования -- SpeedModule1Workshop: Workshop и SpeedModule2Workshop: Workshop, который переиспользует SpeedModule1Workshop, ну и т.д. для SpeedModule3Workshop.
Программистам везде мерещиться ООП. Даже в Factorio ООП не нужен так как завод показанный в видео чрезмерно много место занимает, а выхлоп - один заводик который долго производит карту. Как делают опытные игроки в Factorio: реализация через шину или сити-блоки на поездах. Принцип шины самый лучший. Идёт огромная шина из конвейеров. Мы стараемся делать такие блоки производства которые берут из шины по максимуму ресурсов и производят полный конвейер продукции, возвращая в шину результат. По сути реализация функционального программирования. И это работает в разы лучше так как конвейеры всегда заполнены по максимуму. Из минусов - ширина шины может быть большой. По этому для решения этой проблемы базу перестраивают под поезда и строят сити-блоки. Там уже другая проблема - размеры сити-блоков бывают огромны. Но зато расширять производство на них проще. Поезда сами куда нужно отвозят товар и сами забирают готовую продукцию. Принцип тот же, только на поездах.
разочарован. я то думал удастся увидеть реализацию наследования в факторке. xD но главная проблема видео - тут нарушается принцип единственной ответственности, изза чего объекты делают сразу много вещей реализую в себе функцию "всего". думаю тут было бы правильней проиллюстрировать классическую шинную или ситиблочную структуру производства где каждый цех выполняет максимально узкую задачу.
ну такое, тут показано как раз что это неэффективно как по мне главный враг ооп это наследование наледование должно быть не для реюза кода, а для выстраивания иерархии типов, не более
Поймите наконец-то!!! Когда кто-то берется объяснять ООП, это значит люди, что которые хотят узнать о ООП или начать внедрять в свои проекты, хотят посмотреть РАЗНИЦУ!!! Т.е. я пишу процедурно...ага работает но по формлению кал. А как бы было тоже самое,но через ООП. Т.е. нужно очень четко сравнить преимущества, чтобы человек видел и такой: "Аааа, так это же проще, вот оно как делается". А не так: "Да, круто! Но чет страхово переводить свой проект на ООП". Т.е. нужно показать на примере реализации одной и той же задачи. Грязный код VS ООП. И меееедленно,как для слоупоков, пояснять, что вот этот кусок мы переписываем, иначе в дальнейшем мы просто не сможем в масштабирование
При объяснении ООП всегда рассматривают 3 либо 4 принципа. Но почему-то мало где говорят, в чём вообще смысл слов "объектно-ориентированное", в чём выражается та самая "ориентированность на объекты". Есть ёмкая фраза насчёт этого, и насчёт инкапсуляции в частности. Звучит примерно так: "объединение данных и методов работы с ними". Т.е. всё, что можно делать с данными (методы, функции, операторы), описаны в одном месте (классе) с этими данными. Правда, как это переложить на Факторио -- не знаю :)
Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма: 1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :) 2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.
Попытка хорошая в правильном направлении Правда мне сразу понятно (программирую больше 10 лет), что Автор не програмист Абстракция это основа проектирования любого ПО впринципе - ты когда создаешь что-то сложнее чем г*вно и палки всегда в голове представляешь какую то абстракцию системы и её модулей, как они взаимодействуют друг с другом. Также за полиморфизм не объяснил ничего толком "Использует весь функционал" - это не полиморфизм друже Поли - много. Морф - форма структура Тоесть с одним и тем же объектом можно взаимодействовать как с разными структурами: Например класс Человек - это животное но с ним можно говорить Тоесть мы можем говорить с объектом человек1 Но также этот самый объект мы можем покормить так как он является Животным (наследуется от класса Животное) Грубо говоря это и есть полиморфизм - мы можем взаимодействовать с человеком как с человеком либо как с животным. Мне кажется в факторио не получится показать полиморфизм - бо скорее всего получится спагетти фабрика :D Но как говорится всё в ваших ногах.
Про ООП написано много мутных слов, проблема в том, что в определении ООП перечислены принципы, а под ними можно понимать разные вещи. То есть само определение мутное) Поэтому рекомендую читать классику - "Чистую архитектуру" дяди Боба. Он пожил, он знает. Тем более, что он вертел эти ваши принципы и показывает, что не ООП язык их вполне себе поддерживает. Лично я считаю основополагающими для ООП только два принципа - инкапсуляцию и полиморфизм. Причем самый интересный - второй. С первым понятно, это сама возможность строить объекты и смотреть на них как на черный ящик - скрывать детали реализации. Это абстракция данных. А второй - это абстракция методов. Он дает возможность делать интерфейсы, инверсию управления, и все плюшки абстрагирования и контроля зависимостей. Кроме абстракции данных и методов собсно ничего нет, так зачем множить сущности? Без наследования что, объекты не сделать? То есть инкапсуляция позволяет нам строить бесконечно сложные системы, а полиморфизм - делать их части простыми и взаимозаменяемыми. Условно, чтобы можно было использовать разные детали, изготовленные разными людьми в разных местах - основа машиностроения. Ну и Мартин считает ООП-шным только полиморфизм, поддерживающий инверсию зависимостей - интерфейсы. Есть в языке интерфейсы, значит поддерживает ООП. Нет - только какую-то его часть.
Всё же проще в разы: У тебя есть объект, а объект это совокупность стейта\данных и методов\функций. Остальное про инкапсуляцию, и прочую композицию можно просто отбросить, ибо она и функциональной парадигме присуща в равной степени Если на примере факторио говорить: ООП это когда ты завод для железных плит, и всего с ними связанного, на железном руднике строишь прямо на месте. При этом, строишь аналогичный завод но уже на месте медного рудника, даже если заводы похожи как две капли воды. ФП же, в свою очередь, это когда ты строишь кучу мелких фабрик, и начинаешь дрочиться с логистикой ресурсов, делая при этом важное ебало, и яростно пытаешься убедить себя в неотвратимости и "единствоправельности" такого подхода. Короче, либо процедурка на контроллерах, либо AI no-code платформы для клепания крудов, остальное от лукавого! 🫠
Полиморфизм: я не знаю, кто ты, но вот тебе деньги, надеюсь, ты меня не обманешь. Инкапсуляция: когда живешь в однокомнатной и устроил вечеринку. Наследование: бейджик "ламборгини" на тракторе. Вам, конечно, чсв чешется, но то, чем забита ваша голова, и что вы оттуда достаете на собесах - это костыли для кривой архитектуры (к тому же НИКАК не помогающие избегать кривого кода в виде: "земля, копайся").
Только одного меня удивляют заядлые оопэшники, фразами типа: не нужно у класса "работник" дёргать его функции/методы, нужно ему "просто" дать задачу и пусть он её сам решает... А как её дать? Силой мысли? Вся эта тема с парадигмами, выглядит как какая то вера, где если копнуть поглубже, то в ответ получаем - "гладиолус". Вот один уважаемый оопэшник, твердил, что в трушном ооп языке, не должно быть даже ифов и тд.. мол это пережиток. И так вместо обычного иф, должен быть объект, который это сделает. Ну в общем маразм крепчал. Всё меньше здравого смысла, всё больше парадигм и гладиолусов.
С ООП код становится проще?! Или наоборот сложнее? Код без ООП читать проще, чем с ООП, при условии, что его написали понятно. Код как с так и без ООП можно написать так, что в нём ничего будет не понятно, тут уж в зависимости от поставленной задачи: написать так, чтобы другим было понятно; или написать так, чтобы никто ничего не понял...
В факторио нет интерфейсов. Какое ооп? Ну и ооп не про качественный код. Обычно это ебаный пиздец. Либо легаси с чейном наследования 10 классов, либо кошмар с ДИ, фасадами, все дергается непонятно откуда и т.д. Лично я в факторио хуярю ситиблоки на железной дороге, похоже на шину с микросервисами, хз как ты к этому приплел ооп) А так как ты показал строиться получиться спагети и в мид-гейме уже начнешь охуевать и строить костыли(прямо как с реальным ооп =))
полиморфизм - это не "выдача объектом всего функционала, что он умеет" полиморфизм - это единообразие обращения с объектами разного типа через один и тот же интерфейс, встроенный в них. механизмы предоставления такого интерфейса могут быть разными, но суть та же: обрабатывать разные объекты одним способом. иными словами, не переобучая рабочий узел работе с разными сущностями, всё-же, получать от него обработку широкого спектра этих сущностей, всего лишь внедрив в них одинаковый интерфейс обращения. так, в реальной жизни, человек может ухватиться за любой поручень или ручку. всё, к чему приделана "рукоятка" в форме изогнутой палки, подходит в качестве удобного интерфейса для руки - двери, рамы окон, поручни, перила, ручки сумок, прорези коробок, рукоятки ножей, оружия, джойстики, рычаги, рули управления транспортом, всё это - полиморфно обрабатываемые человеческой рукой, как универсальным хватателем, объекты. пример из области программирования - это возможность осуществить операцию сложения двух строк, либо двух чисел, либо чего-то ещё, для чего оперделена операция сложения, при помощи бинарного оператора "+". оператор один и тот же, а типы разные, как разнятся и результаты. но вот способ оперирования - один и тот же: два значения на входе и одно на выходе в качестве результата, что составляет интерфейс операции для полиморфной обработки. ну и конечно же, динамический/статический полиморфизм, предоставляемый механизмом наследования, либо реализации интерфейса (набора методов и/или свойств) и позволяющий получать полиморфность по наследству, любо по структурной схожести, предоставляя возможность для объектов реализовывать обращение к себе со стороны других объектов через хорошо известный интерфейс.
Абстракцию нужно смотреть в современном психологическом справочнике. Каждый объект в современном мире мы рассматриваем как абстракцию, т.е. как множество отдельных свойств присущих объекту, которые можно рассматривать по отдельности, с не как какой-то несокрушимый монолит, это по сути и есть абстрактное мышление. Взять например наш любимый автомобиль каждый представит себе конкретный автомобиль, но в абстракции это транспортное средство которое содержит в себе некое бесконечное количество требований лиц которые его эксплуатируют, лиц которые на етом ездят, лиц которые это чинят, лиц которые это строят, лиц которые это разрабатывают, лиц которые... Думаю идею вы поняли и у каждой группы есть своя абстракция об этом объекте которая важная для одной группы и не очень важная для другойдругой и вроде можно рассматривать всё группы свойств объекта по отдельности, но успешным продуктом размышления будет "синергетический продукт" максимально удовлетворяющий всё группы, но при этом это не значит что ето будет удовлетворять всё группы по максимуму...
за наглядную визуализацию через factorio конечно лайк, но есть пара замечаний: - завод все равно зависит от внешней среды, потому что нефть поставляется в бочках, а значит где-то за кадром есть автомат куда отвозят пустые бочки и отправляют полные. так что с инкапсуляцией тут беда. - вместо руд можно было бы сразу поставлять пластины, один хрен плавильни на базе должны быть. да и электросхемы нет смысла производить внутри этой системы. они производятся в отдельном блоке в больших кол-вах. также с нефтянкой. иначе получается дублирование производства. инкапсуляция в том, что для создания последующих модулей нужен предыдущий. можно было бы сделать один ситиблок, к нему подвести пластины, схемы, пластик, а дублировать бы пришлось только автоматы с модулями. - сбор модуля 1 - сбор модуля 1 + модуль 2 - модуль 2 + модуль 3 как должно быть проще для восприятия. нет нужды дублировать производство базовых ресурсов. да и полной автономии добиться нельзя, все равно где-то должен стоять генератор, ситиблоки для руд, мол и тд
на самом деле если вообще всю базу сделать из ситиблоков, то будет ооп. в каждом блоке свое производство, независимо от другого. наследование - когда для одного ситиблока требуется ресурс из другого. пример: производство схем или банок. ну и сама база это объект
Извини, автор, но объяснение ни о чем. Ничем не лучше сотен других примитивных. Вот я знаю ООП и почти не применяю. У меня простые задачи которые решаются процедурным программированием: взять инфу из бд, обработать, выдать результат. ООП как парадигма имеет смысл в маленьких задачах в очень узком диапазоне применения, а вот в больших задачах ООП упрощает работу. И связано это непосредственно с архитектурой приложения и взаимодействии компонентов. Вот тут у объясняторов от ООП пробелы
Честно говоря, я руду переплавляю в плиты прямо у месторождений. А на сборщики подаю плиты с поездов, через конвейеры. Иногда даже второй передел (плиты в проволоку) делаю у рудника, а поездами развожу. Но ролик всё равно хорош!
ООП это именно что удобство понятность и структурированность для любого пользователя чтеца или редактора кода, но никак не оптимальный способ выполнить конкретную задачу. Если у человека есть желание сделать своё "чудо", то ООП не его вариант в 80% случаев.
Если уж говорить об ООП применительно к играм, то обязательно нужно упомянуть Space Engineers. Это та игра, где C# можно изучить. Там все системы на иерархии различных интерфейсов построены. И заодно изучить векторную алгебру - там 3D пространство со всеми вытекающими: векторы, матрицы...
Я в програмировании новичек и может так ооп и работает? Но с точки зрения механики факторки, база просто ужасная с минимальной производительностью. Начиная с того что на шинах не переплавленный металл, а руда. Скорость создания проводов настолько большая что туда можно загружать металл с 3х манипуляторов, а значит не нужно их дублировать. Да и схемы можно было бы отдельно производить, а потом завозить туда где тебе нужно.
Я до сих пор не могу принять мозгами ооп, для меня это бред, не зря я говорил, что ооп - это удел инженеров 🤣 не считаю, что ооп это правильно, а где ещё виды ооп, их вроде 4 вида, не только классы как в java - подобном синтаксисе
Пиши комментарии в коде с примерами краткими входящими данными и результатом что на выходе должно быть. И тогда поймет любой программист. Остальное мутные слова с заумными формулировками.
Чел ты либо накурился ,либо хз. В реальной жизни ООП на практике неприменимо , слишком много зависимостей , не получится даже класс изолированный создать
Факторка все таки микроконтроллер, слишком низкого уровня. Такую абстракцию как функцию ввести невозможно. Без копирования элементов далеко не уедешь. Это полностью соответсвует проектированию микроконтроллеров.
Честно говоря... это полный бред. Принципы ООП ложатся на данный пример из факторио не "удивительно хорошо", а чертовски криво и притянуто, и скорее "графически", чем идейно (в факторке просто нет нужных для такого механик). Только хорошо понимая и то и другое, можно уловить какие-то сверхтонкие общие черты (кроме полиморфизма, про него вообще какая-то хрень непонятная написана). Не советовал бы новичкам пытаться понять что-то на основании этого примера, почитайте лучше нормальные статьи по ООП.
Да-да-да. Всё как в жизни. Сделал один объект красивым, остальные идут в жертву. Например пластик. Копипаста такая линейных участков кода. Потом начинаешь вылизывать объект производства пластика, что-то третье идёт по швам. Третье переделал - другие два надо перепилить. Весь проект этим и занимаешься. Нужно правильно выбирать парадигму. Видел "шедевр" однажды как банковские процессы на ООП писали. Объект "кредит" у меня в мемах.
Если задача плохо решается в объектной парадигме - не надо руками и ногами запихивать в неё решение)) Да, в остальную систему всё-равно придётся наверняка встраивать в виде объекта, но никто не мешает внутри сделать так, как было бы удобнее.
Отличный мод. Очень удобно разделять производства по ангарам и потом соединять либо последовательно, либо параллельно, в зависимости от способа распределения производств.
Только как бы то небыло, но в факторио выгоднее разносить производство по разным местам, в одном месте плавить железо, в другом медь, в другом нефть, так зачастую получаеися эффективние) (p.s. LTN сушествует)
На практике вопрос архитектуры - трейд между целями и ресурсами. Если надо дешево и быстро, без потенциала в расширение, то зачем тратиться на что-то кроме функционального подхода ? Если нужно сделать часть проекта доступной для работы менее квалифицированного работника, зачем много уровней абстракций ? И тд.
Потому что Yagni. Если заглядывать под капот маленьким проектам то там либо какой-то мощный фрейморк или ядро, где по сути все ООП уже написано, а программист просто создает готовые экземпляры готовых классов и пользуется готовыми методами, не раскрывая и 20% фреймоврка с которым работает, потому что в его целях это просто не нужно. На гитхабе очень сложно найти репы написанные с 0 для какой-то коммерции, так как они все закрыты. Честно говоря об ООП парадигме, она просто во многих случаях не нужна и раздувает твой код.
Главный враг и спутник любого факториста - "пока так, потом перестрою"
А потом лень, я лучше новое добавлю рядом а старое будет стоять
В программировании также если что =)
@@djojbbhf Да, я строю новый завод, который покрывает объемы производства старого, стопаю старое производство, сношу старое производство.
В программировании точно так же: есть хреново спроектированая подститсема, но на момент создания она устраивала. Проектируется новая, имплементируется, возможно часть функционала переводится, бывает параллельно работают обе... в конце концов переводится вся работа приложения на новую подсистему, выпиливается старая.
Нет ничего постояннее, чем временное)))
И программиста....
Это безумно хорошо и наглядно. Даже мотивирует писать именно так.
Видны простои ресурсов, например медной проволоки, потому что не учтены соотношения. По наглядности все отлично, по эффективности не очень.
9:30 Но так же можно сказать про функциональщину и чистые функции, кек.
Полиморфизм вообще мимо, по-моему.
Появился ролик, который чётко раскладывает принципы ООП по полочкам Факторио, насколько это возможно. "Парадигма ООП в Factorio, или как натянуть сову на глобус": ruclips.net/video/N8Q9TwwsVcI/видео.html
Хотя и там я не со всем согласен.
Ооп - раковая опухоль поражающая код плохих инженеров.
Пример, откровенно кладущий на половину принципов программирования.
Объект рабочий, но не эффективен. Эдакий универсальный папа Карло
Не спросят а поинтересуются.
B l y a chel 😢
Я: наблюдаю, как для производства модулей к заводам поступает руда вместо готовых плит.
Мой глаз: **дергается как тварь**
Во во, получеться что "объект" отвечает не только за работу с "данными", но и за их "парсинг", чем нарушает принцып Singe responsibility. Сити блоки куда ближе по сути к архитектуре програмирования
Чётко, понятно, но только для тех, кто в теме. Проще надо быть, и люди к тебе потянутся. Например начать играть и создавать базу параллельно комментируя основы программирования.
Пожалуй худшее объяснение ооп которое мне попадалось)
После такого пояснения появляется желание ввести игру factorio в образовательную программу.
Никто из опытных игроков так не строит базу. Это очень не эффективно, только один сборщик который долго производит одно улучшение.
Множество раз слышал о таких идеях
Принуждение не приведет ни к чему хорошему, можно сделать добровольные уроки в замен пению, физре, изо или другому второстепенному что бы просто попробовали и если понравится - учились, не понравилось - не учились, главное что бы измененная программа не добавляла и не убавляла часов, что бы не абъюзить систему
@@Spectre4490политические уроки каждый год добавляют новые и не задумываются об этом)))
в факторио можно много разных концепций моделировать, но это не значит, что нужно их из одной сферы в другую тащить, это просто наглядное пособие, но никто так строить производство не будет в игре, это не эффективно
Как ни странно, но объяснение из вики о том, что "всё должно быть на объектах" гораздо точнее описывает суть ооп чем остальные 99% этого ролика.
@Bionic_Budda в функциях.
@Bionic_Budda структуры данных.
@Bionic_Budda можно и так рассмотреть.
@Bionic_Budda это адресовано мне?
@Bionic_Budda я просто спросил, хз чего ты психанул.
а можно играть на "микросервисной архитектуре", на так назывемых сити блоках. каждый ситиблок это территория, огражденная железной дорогой, например квадратики 100 на 100 рельм. на такой ситиблок можно завохить ресурсы и забирать. каждый ситиблок отвечает за создание конкретного ресурса. например плавильный ситиблок, или ситиблок создающий все предсеты в игре, необходимые для строителства других ситиблоков, так называемый дрон молл. можно создать чертежи под каждый ситиблок и ресурс в игре, а также чертеж самого ситиблока, который имеет относительную привязку, благодаря чему можно не отпуская мышку поставить 100 ситиблоков на чертеж. по границе ситиблока и внутри можно установить дрон станции, за счет чего дроны будут брать рельсы и все прочие ресурсы из молл ситиблока и строить ваши ситиблоки, а вам останется лишь разрабатывать залжеи ресурсов, обеспичвать базу энергией(если строить сити блок на воде, то в один ситиблок влезет 4 реактора, суммарной мощностью 4.4 гвт, что при большом обьеме производства не так и много)
Этой архитектуре отлично подходит мод LTN - Logistic Train Network. Этот мод вводит дополнительную логику для поездов, которая позволяет им ездить из депо, куда угодно, чтобы забирать или отвозить ресурсы кому нужно. Станции в таком случае делятся на 2 типа: Provider - станция поставщик ресурсов из подключенного хранилища и Requester - станция, запрашиватель ресурсов из Prodiver станций.
Ну ситиблоки - это и есть модули, созданные под конкретную задачу и отвечающие всем требованиям объектного проектирования
Так и делал, в принципе рабочая схема, но масштабируется тяжело. Будущее за суперблоком - ситиблок, который на вход принимает 5 базовых ресурсов (4 руды и нефть), производит всю науку одновременно и всю ее перерабатывает. Далее просто копипастим суперблок столько сколько науки хотим (вытягивает процессор), нарасчиваем добычу, вытесняем кусак. Сюда нужна обслуживающая инфраструктура (электроэнергетика, заправка поездов, молл) - ее можно оставить на ситиблоках.
Правда играть становится не интересно.
@@user-ch76tcye4vvuu8 вот да, не интересно играть это точно подмечено. самый большой рост заводчанина это приход понимания что спагетти весело до поры до времени, потом тебя это начинает бесить и тебя осеняет что можно производить все по отдельности и выводить на общую шину. после ты переходишь на полный формат базы на шине, дальше на ситиблоки и тд и понимаешь "ах, какое же спагетти вкусное было" и возвращаешься к началу начал :)
Теперь паттерны в программировании через factorio
на Хабре видел кстати статью о реализации архитектурных паттернов на factorio, оттуда и узнал про игру
Мда, Федор объяснил конечно намного лучше, нагляднее, но что главное более подробно из без воды на пол ролика
У этой схемы эффективность стремится к нулю. Производство "по месту" - не очень, так как мы, строим лишние заводы, что эквивалентно повторному коду. Для избежания таких повторений в языках придумали - функции, а в факторке - "цеха" (Просто массив заводов, которые будут обеспечивать всю фабрику, делая её более "читабельной" и менее "мокоронной". И при всём при этом, если массив достаточно большой, уменьшает время ожидания изготовления предмета
Продолжи аналоги, если дроны это аякс, а руда это sql, то его функционал ляжет от 10 посетителей.
Иди учи мат часть ооп, ты не прав!
@@TestTest-cr2xb И в чём же?
@@p.k.r.7963 Когда ты указываешь на неэффективные элементы и предлагаешь пути оптимизации, ты почти наверняка прав. А когда тестер говорит что оптимизация там не нужна, он точно не прав.
Чел тут он наглядно показывает как ооп работает, он ресурс дронами привозит 🤷♂️ о чем речь тут все для наглядности а не для эффективности
Спасибо🤝
Пожалуй вы 1 человек в ютьюбе кто рассказал об ООП понятно. Как говорится кто ясно мыслит тот ясно говорит.
Маленькая ирония в том, что факторио написан с помощью подхода, ориентированного на данные, а не объекты.
Я как истинный любитель натянуть сову на глобус и подумать о вечном, а также загрузить коллегу за чашкой смузи в офисе (которого у меня больше нет) провел не мало часов размышляя о том что же не так с ООП и как его исправить.. Я пришел к выводу, что концепция ООП не ложиться в концепцию вычислительных машин.. Ни один язык который я изучал в надежде найти тот самый ООП не дал ощущения работы с объектами.. Везде я работаю с алгоритмами и данными, а объекты эти ваши - прикол какой-то который все привыкли писать, а еще писать про них толстенные книги и рубить бабло на них)
Мне кажется эта некая попытка стандартизировать программирование.. Якобы нарубал себе объектов как шестерен и работаешь с ними, собирая то ли часы то ли ракету, но только каждый объект сука личность и каждая запятая в нем важна.. Вот и получается, что всегда нужно лезть своими грязными ручонками в реализацию и крутить хвосты каждому объекту в индивидуальном порядке.
В общем и целом мне кажется, чтобы построить коммуни... Извините... То есть что бы получить чистый ООП, ты как программист должен оперировать объектами.. Жонглировать ими, но никогда не залазить в их реализацию, что к сожалению не возможно на том уровне абстракции, где мы сейчас находимся..
Так что всем бобра..
ЗЫ: Я так и не пон, причем тут факторио к ООП... Объясните, люди добрые :)
прикол в том, что ты и описал. просто визуально показал чел, что делаются "кубики", из которых потом что-то мастерится
Немножечко понимаю, что такое ООП. Немножечко пользуюсь. Но не владея контекстом игры от такой визуализации мне ничего понятнее не стало. Вернее, на словах концепцию и аналогию с игровым конвейером я понял, а иллюстрация какая-то не понятная. Я не понял, что она иллюстрирует.
Вот так объяснил) По традиции - переделывай ролик.
Абстракция в игре - это в самом примитивном виде архитектурный подход к строительству фабрики. Макароны, шина, сити-блоки. Это примеры абстракции. Когда вся суть своидтся к моделированию сущностей и их взаимодействия. Сущности тут будут представлены как некие цеха или блоки цехов, а взаимодействие - система транспорта. Ленты, дроны, поезда.
Инкапсуляция - это любой законченный цех, получающий на вход продукт X, выдающий продукцию Y. При этом взаимодействие с цехом идёт только через входные-выходные интерфейсы. Ленты, или жд станции, например. Или весь пример в ролике, производящий модули трёх типов из базового ресурса.
Наследование можно рассмотреть с точки зрения композиции и агрегации. Пример композиции - это совокупность модуля и сборочного автомата. А агрегация - это совокупность манипулятора и сборочного автомата. Подобные конструкции применяются всегда и везде.
Полиморфизм тоже можно рассмотреть с разных сторон.
Ad-hoc представляется в виде совокупности сборочного автомата и разных рецептов в нём. Тут проволка, там шестерни. Параметрический полиморфизм - это в целом возможность менять рецепты внутри сборочников. Полиморфизм подтипов можно представить на уровне двух цехов, производящих железные пластины. Один цех производит на обычных печках, другой - на электропечах.
Нельзя натянуть сову на глобус, не рассматривая сабж в комплексе.
Вся суть ООП в том, что вы пишите код, который работает с абстракциями, а не напрямую с данными. Классы это шаблоны объектов, поэтому вы можете указать, что вы передаёте не некий объект, а объект соответствующий определённому шаблону. Ну и нужно понимать, что приложение это уже объект и невозможно написать программу, которая бы полностью была написана на ООП, всегда будет какаято часть императивного кожа, включая программные объекты. Завод в факторио никак не объясняет ООП, это просто работающая программа, каждый заводик это объект, а абстракции автор предлагает держать в голове, ну это не ООП подход.
Блин, даже за 2 года всего 676подписчиков, у тебя отличный контент, желаю дальнейшего развития канала и продвижения контента ютубом.
но ведь в примере в конце нарушен по сути базовый приинцип "Don't repeat yourself". причем настолько грубо, насколько это вообще возможно ))
а так игра великолепна )
Факторка скорее процессор чем код.
сразу видно что автор не программист, после слов "абстракция - это так себе")))
если функционал из заводика 1 нужно поменять, то придется не только пересобирать наследующиеся от 1го завода объекты: 2,3,4, но и предусмотреть ситуации в которых поведение 1го влияет на остальных
Только через добавление, расширение, добавится абстракция.
Требую продолжения :) Продолжай в том же духе . Когда ждать продолжения ?????
Факторио гениальная игра
Ну это какое-то очень далекое описание. Почему бы просто не сформулировать что основа ООП это по сути группировка вложенных сущностей по функционалу, где более высокий уровень содержит общие черты присущие большинству низкоуровневых, а на низких уровнях соответственно растет специализация.
А полиморфизм, это когда ваську сводили к ветеринару )))
Почему бы не попить чай до записи ролика?
UPD: лучше ролик не записывать, если такие проблемы со знаниями в сфере/формулировкой мысли
Большего бреда я в жизни не слышал
Видео отлично, но нужно поработать над подачей информации. Сильно затягиваете
Благодаря этому ролику понимание ООП усложнилось в 50000 раз. В университете, давным давно, парадигма ООП гораздо проще объяснялась на примере игры в шахматы. Но автору надо отдать должное за оригинальный, не тривиальный, подход к раскрытию сути ООП. Лайк.
С автором согласен, что в подавляющем большинстве мелких проектов не используется ООП.
Приветствую! Не могли бы Вы Пересказать хотя бы вкрадце это объяснение на примере шахмат? Было бы интересно узнать
тоже интересно что за объяснение на шахматах
Схема в конце по-моему великовата, наверное это всё можно было бы ужать
Это скорее пример композиции, нежели наследования. Если завод модуля скорости 2 наследует завод модуля скорости 1, то он может производить на выход модуль скорости 1. Но это не так, он выдает модуль скорости 2!! Тут разве что один уровень наследования -- SpeedModule1Workshop: Workshop и SpeedModule2Workshop: Workshop, который переиспользует SpeedModule1Workshop, ну и т.д. для SpeedModule3Workshop.
Программистам везде мерещиться ООП. Даже в Factorio ООП не нужен так как завод показанный в видео чрезмерно много место занимает, а выхлоп - один заводик который долго производит карту.
Как делают опытные игроки в Factorio: реализация через шину или сити-блоки на поездах.
Принцип шины самый лучший. Идёт огромная шина из конвейеров. Мы стараемся делать такие блоки производства которые берут из шины по максимуму ресурсов и производят полный конвейер продукции, возвращая в шину результат. По сути реализация функционального программирования. И это работает в разы лучше так как конвейеры всегда заполнены по максимуму.
Из минусов - ширина шины может быть большой. По этому для решения этой проблемы базу перестраивают под поезда и строят сити-блоки.
Там уже другая проблема - размеры сити-блоков бывают огромны. Но зато расширять производство на них проще. Поезда сами куда нужно отвозят товар и сами забирают готовую продукцию. Принцип тот же, только на поездах.
разочарован. я то думал удастся увидеть реализацию наследования в факторке. xD
но главная проблема видео - тут нарушается принцип единственной ответственности, изза чего объекты делают сразу много вещей реализую в себе функцию "всего".
думаю тут было бы правильней проиллюстрировать классическую шинную или ситиблочную структуру производства где каждый цех выполняет максимально узкую задачу.
ну такое, тут показано как раз что это неэффективно
как по мне главный враг ооп это наследование
наледование должно быть не для реюза кода, а для выстраивания иерархии типов, не более
Вы ведь на go пишете, так?)
@@trabloid rust, go, typescript, изредка C++
Ооп э о деградантская философия, по замыслу тормозная
Поймите наконец-то!!! Когда кто-то берется объяснять ООП, это значит люди, что которые хотят узнать о ООП или начать внедрять в свои проекты, хотят посмотреть РАЗНИЦУ!!!
Т.е. я пишу процедурно...ага работает но по формлению кал. А как бы было тоже самое,но через ООП. Т.е. нужно очень четко сравнить преимущества, чтобы человек видел и такой: "Аааа, так это же проще, вот оно как делается". А не так: "Да, круто! Но чет страхово переводить свой проект на ООП".
Т.е. нужно показать на примере реализации одной и той же задачи. Грязный код VS ООП. И меееедленно,как для слоупоков, пояснять, что вот этот кусок мы переписываем, иначе в дальнейшем мы просто не сможем в масштабирование
При объяснении ООП всегда рассматривают 3 либо 4 принципа. Но почему-то мало где говорят, в чём вообще смысл слов "объектно-ориентированное", в чём выражается та самая "ориентированность на объекты". Есть ёмкая фраза насчёт этого, и насчёт инкапсуляции в частности. Звучит примерно так: "объединение данных и методов работы с ними". Т.е. всё, что можно делать с данными (методы, функции, операторы), описаны в одном месте (классе) с этими данными.
Правда, как это переложить на Факторио -- не знаю :)
Пока вики цитировал было норм, потом скатился к собственным рассуждениям и потерпел фиаско. Что за бред я посмотрел?
Один из видов полиморфизма -- перегрузка методов в нескольких формах, с разными аргументами и разной реализацией. В Факторио можно было бы хорошо это показать, вот несколько вариантов полиморфизма:
1. Один и тот же модуль даёт разные продукты в зависимости от поступивших аргументов. В этом видео, например, можно подавать в модуль медь и железо и получать первые (зелёные) платы, а если добавить нефть -- получатся уже вторые и третьи (красные и синие) платы. Хоть в начале на этот модуль потратишь больше ресурсов, но после появления нефти он без перестройки будет выполнять доп. функционал. В Факторио это невыгодно, а в программировании лишние строки кода есть не просят :)
2. Плавильный цех может выполнять одну функцию, но быть построен из печей разного вида. Имеем разные формы (реализации) класса, выполняющие одну функцию.
Попытка хорошая в правильном направлении
Правда мне сразу понятно (программирую больше 10 лет), что
Автор не програмист
Абстракция это основа проектирования любого ПО впринципе - ты когда создаешь что-то сложнее чем г*вно и палки всегда в голове представляешь какую то абстракцию системы и её модулей, как они взаимодействуют друг с другом.
Также за полиморфизм не объяснил ничего толком
"Использует весь функционал" - это не полиморфизм друже
Поли - много. Морф - форма структура
Тоесть с одним и тем же объектом можно взаимодействовать как с разными структурами:
Например класс Человек - это животное но с ним можно говорить
Тоесть мы можем говорить с объектом человек1
Но также этот самый объект мы можем покормить так как он является Животным (наследуется от класса Животное)
Грубо говоря это и есть полиморфизм - мы можем взаимодействовать с человеком как с человеком либо как с животным.
Мне кажется в факторио не получится показать полиморфизм - бо скорее всего получится спагетти фабрика :D
Но как говорится всё в ваших ногах.
Про ООП написано много мутных слов, проблема в том, что в определении ООП перечислены принципы, а под ними можно понимать разные вещи. То есть само определение мутное)
Поэтому рекомендую читать классику - "Чистую архитектуру" дяди Боба. Он пожил, он знает. Тем более, что он вертел эти ваши принципы и показывает, что не ООП язык их вполне себе поддерживает.
Лично я считаю основополагающими для ООП только два принципа - инкапсуляцию и полиморфизм. Причем самый интересный - второй.
С первым понятно, это сама возможность строить объекты и смотреть на них как на черный ящик - скрывать детали реализации. Это абстракция данных. А второй - это абстракция методов. Он дает возможность делать интерфейсы, инверсию управления, и все плюшки абстрагирования и контроля зависимостей. Кроме абстракции данных и методов собсно ничего нет, так зачем множить сущности? Без наследования что, объекты не сделать?
То есть инкапсуляция позволяет нам строить бесконечно сложные системы, а полиморфизм - делать их части простыми и взаимозаменяемыми. Условно, чтобы можно было использовать разные детали, изготовленные разными людьми в разных местах - основа машиностроения. Ну и Мартин считает ООП-шным только полиморфизм, поддерживающий инверсию зависимостей - интерфейсы. Есть в языке интерфейсы, значит поддерживает ООП. Нет - только какую-то его часть.
Всё же проще в разы: У тебя есть объект, а объект это совокупность стейта\данных и методов\функций. Остальное про инкапсуляцию, и прочую композицию можно просто отбросить, ибо она и функциональной парадигме присуща в равной степени
Если на примере факторио говорить: ООП это когда ты завод для железных плит, и всего с ними связанного, на железном руднике строишь прямо на месте. При этом, строишь аналогичный завод но уже на месте медного рудника, даже если заводы похожи как две капли воды.
ФП же, в свою очередь, это когда ты строишь кучу мелких фабрик, и начинаешь дрочиться с логистикой ресурсов, делая при этом важное ебало, и яростно пытаешься убедить себя в неотвратимости и "единствоправельности" такого подхода.
Короче, либо процедурка на контроллерах, либо AI no-code платформы для клепания крудов, остальное от лукавого! 🫠
Полиморфизм: я не знаю, кто ты, но вот тебе деньги, надеюсь, ты меня не обманешь. Инкапсуляция: когда живешь в однокомнатной и устроил вечеринку. Наследование: бейджик "ламборгини" на тракторе.
Вам, конечно, чсв чешется, но то, чем забита ваша голова, и что вы оттуда достаете на собесах - это костыли для кривой архитектуры (к тому же НИКАК не помогающие избегать кривого кода в виде: "земля, копайся").
Проблема в балансировке. Где то 2 завода овермного, где то нужно 20 ставить чтобы спрос удовлетворить, отсюда вермишель
Ну так там есть цифры соотношения сам считай
Только одного меня удивляют заядлые оопэшники, фразами типа: не нужно у класса "работник" дёргать его функции/методы, нужно ему "просто" дать задачу и пусть он её сам решает...
А как её дать? Силой мысли?
Вся эта тема с парадигмами, выглядит как какая то вера, где если копнуть поглубже, то в ответ получаем - "гладиолус".
Вот один уважаемый оопэшник, твердил, что в трушном ооп языке, не должно быть даже ифов и тд.. мол это пережиток.
И так вместо обычного иф, должен быть объект, который это сделает. Ну в общем маразм крепчал.
Всё меньше здравого смысла, всё больше парадигм и гладиолусов.
С ООП код становится проще?! Или наоборот сложнее? Код без ООП читать проще, чем с ООП, при условии, что его написали понятно. Код как с так и без ООП можно написать так, что в нём ничего будет не понятно, тут уж в зависимости от поставленной задачи: написать так, чтобы другим было понятно; или написать так, чтобы никто ничего не понял...
В факторио нет интерфейсов. Какое ооп? Ну и ооп не про качественный код. Обычно это ебаный пиздец. Либо легаси с чейном наследования 10 классов, либо кошмар с ДИ, фасадами, все дергается непонятно откуда и т.д. Лично я в факторио хуярю ситиблоки на железной дороге, похоже на шину с микросервисами, хз как ты к этому приплел ооп) А так как ты показал строиться получиться спагети и в мид-гейме уже начнешь охуевать и строить костыли(прямо как с реальным ооп =))
полиморфизм - это не "выдача объектом всего функционала, что он умеет"
полиморфизм - это единообразие обращения с объектами разного типа через один и тот же интерфейс, встроенный в них. механизмы предоставления такого интерфейса могут быть разными, но суть та же: обрабатывать разные объекты одним способом. иными словами, не переобучая рабочий узел работе с разными сущностями, всё-же, получать от него обработку широкого спектра этих сущностей, всего лишь внедрив в них одинаковый интерфейс обращения. так, в реальной жизни, человек может ухватиться за любой поручень или ручку. всё, к чему приделана "рукоятка" в форме изогнутой палки, подходит в качестве удобного интерфейса для руки - двери, рамы окон, поручни, перила, ручки сумок, прорези коробок, рукоятки ножей, оружия, джойстики, рычаги, рули управления транспортом, всё это - полиморфно обрабатываемые человеческой рукой, как универсальным хватателем, объекты. пример из области программирования - это возможность осуществить операцию сложения двух строк, либо двух чисел, либо чего-то ещё, для чего оперделена операция сложения, при помощи бинарного оператора "+". оператор один и тот же, а типы разные, как разнятся и результаты. но вот способ оперирования - один и тот же: два значения на входе и одно на выходе в качестве результата, что составляет интерфейс операции для полиморфной обработки.
ну и конечно же, динамический/статический полиморфизм, предоставляемый механизмом наследования, либо реализации интерфейса (набора методов и/или свойств) и позволяющий получать полиморфность по наследству, любо по структурной схожести, предоставляя возможность для объектов реализовывать обращение к себе со стороны других объектов через хорошо известный интерфейс.
Чувак ты в корне не понял ООП =)
ну напиши как ты понял а то складывается впечатление что ты сам не знаешь
@@plohuena69 давайте для начала начмнем с концеции: "Класс" объекта и "Инстанс" объекта.
И ?@@unlike777
@@РоманГапонов-л5й если у тебя возникает вопрос, то к сожалению ты тоже не понимаешь смысла
А что вам мешает записать свое видео на ютубе и обьяснить свою версию понимания ООП?
Все это прекрасно, но требования бизнеса всегда ломают стройную картину твоей чистой архитектуры.
Абстракцию нужно смотреть в современном психологическом справочнике. Каждый объект в современном мире мы рассматриваем как абстракцию, т.е. как множество отдельных свойств присущих объекту, которые можно рассматривать по отдельности, с не как какой-то несокрушимый монолит, это по сути и есть абстрактное мышление. Взять например наш любимый автомобиль каждый представит себе конкретный автомобиль, но в абстракции это транспортное средство которое содержит в себе некое бесконечное количество требований лиц которые его эксплуатируют, лиц которые на етом ездят, лиц которые это чинят, лиц которые это строят, лиц которые это разрабатывают, лиц которые... Думаю идею вы поняли и у каждой группы есть своя абстракция об этом объекте которая важная для одной группы и не очень важная для другойдругой и вроде можно рассматривать всё группы свойств объекта по отдельности, но успешным продуктом размышления будет "синергетический продукт" максимально удовлетворяющий всё группы, но при этом это не значит что ето будет удовлетворять всё группы по максимуму...
за наглядную визуализацию через factorio конечно лайк, но есть пара замечаний:
- завод все равно зависит от внешней среды, потому что нефть поставляется в бочках, а значит где-то за кадром есть автомат куда отвозят пустые бочки и отправляют полные. так что с инкапсуляцией тут беда.
- вместо руд можно было бы сразу поставлять пластины, один хрен плавильни на базе должны быть. да и электросхемы нет смысла производить внутри этой системы. они производятся в отдельном блоке в больших кол-вах. также с нефтянкой. иначе получается дублирование производства. инкапсуляция в том, что для создания последующих модулей нужен предыдущий.
можно было бы сделать один ситиблок, к нему подвести пластины, схемы, пластик, а дублировать бы пришлось только автоматы с модулями.
- сбор модуля 1
- сбор модуля 1 + модуль 2
- модуль 2 + модуль 3
как должно быть проще для восприятия. нет нужды дублировать производство базовых ресурсов. да и полной автономии добиться нельзя, все равно где-то должен стоять генератор, ситиблоки для руд, мол и тд
Хороший ответ, наглядно ООП рассыпалась
на самом деле если вообще всю базу сделать из ситиблоков, то будет ооп. в каждом блоке свое производство, независимо от другого. наследование - когда для одного ситиблока требуется ресурс из другого. пример: производство схем или банок. ну и сама база это объект
Извини, автор, но объяснение ни о чем.
Ничем не лучше сотен других примитивных. Вот я знаю ООП и почти не применяю. У меня простые задачи которые решаются процедурным программированием: взять инфу из бд, обработать, выдать результат.
ООП как парадигма имеет смысл в маленьких задачах в очень узком диапазоне применения, а вот в больших задачах ООП упрощает работу. И связано это непосредственно с архитектурой приложения и взаимодействии компонентов. Вот тут у объясняторов от ООП пробелы
Сколько я знаю factirio построена на data-oriented design так что плохой пример можно было выбрать пальцем в небо почти на любую игру кроме этой😂
Как я тебя понимаю, 50 000 ракет запущено, программист.......java
Честно говоря, я руду переплавляю в плиты прямо у месторождений. А на сборщики подаю плиты с поездов, через конвейеры. Иногда даже второй передел (плиты в проволоку) делаю у рудника, а поездами развожу.
Но ролик всё равно хорош!
ООП это именно что удобство понятность и структурированность для любого пользователя чтеца или редактора кода, но никак не оптимальный способ выполнить конкретную задачу. Если у человека есть желание сделать своё "чудо", то ООП не его вариант в 80% случаев.
Если уж говорить об ООП применительно к играм, то обязательно нужно упомянуть Space Engineers. Это та игра, где C# можно изучить. Там все системы на иерархии различных интерфейсов построены. И заодно изучить векторную алгебру - там 3D пространство со всеми вытекающими: векторы, матрицы...
Я в програмировании новичек и может так ооп и работает? Но с точки зрения механики факторки, база просто ужасная с минимальной производительностью. Начиная с того что на шинах не переплавленный металл, а руда. Скорость создания проводов настолько большая что туда можно загружать металл с 3х манипуляторов, а значит не нужно их дублировать. Да и схемы можно было бы отдельно производить, а потом завозить туда где тебе нужно.
Я до сих пор не могу принять мозгами ооп, для меня это бред, не зря я говорил, что ооп - это удел инженеров 🤣
не считаю, что ооп это правильно, а где ещё виды ооп, их вроде 4 вида, не только классы как в java - подобном синтаксисе
Пиши комментарии в коде с примерами краткими входящими данными и результатом что на выходе должно быть. И тогда поймет любой программист. Остальное мутные слова с заумными формулировками.
Чел ты либо накурился ,либо хз. В реальной жизни ООП на практике неприменимо , слишком много зависимостей , не получится даже класс изолированный создать
Факторка все таки микроконтроллер, слишком низкого уровня. Такую абстракцию как функцию ввести невозможно. Без копирования элементов далеко не уедешь. Это полностью соответсвует проектированию микроконтроллеров.
@magla не могли бы вы дать ссылку на ваш публичный репозиторий? ищу примеры хорошей реализации ооп практик. заранее спасибо
Пхапхааа
Сам говорил объекты должны быть независимые, но заводик 2 наследует заводик 1. Интерфейсы..думаю там так.
Если так непоследовательно и сбивчиво объяснять, то так и не поймёшь что такое ООП.
Автор скачет по темам, не заканчивает мысль и т.д.
Жалко, что в наше время молодёжь совсем разучилась писать ООП
Чувак, завязывай! Объяснять это не твое!!! Тем Более объяснять то что сам толком не понимаешь!!!
Мне кажется это плохой пример. т.к. расширяемости никакой. На мой взгляд в факторио нужен подход микросервисов с шинами ресурсов и продуктов
Честно говоря... это полный бред.
Принципы ООП ложатся на данный пример из факторио не "удивительно хорошо", а чертовски криво и притянуто, и скорее "графически", чем идейно (в факторке просто нет нужных для такого механик). Только хорошо понимая и то и другое, можно уловить какие-то сверхтонкие общие черты (кроме полиморфизма, про него вообще какая-то хрень непонятная написана). Не советовал бы новичкам пытаться понять что-то на основании этого примера, почитайте лучше нормальные статьи по ООП.
За попытку объяснить - спасибо. Само видео - нихера не понял, даже при попытке притянуть сюда факторио.
Класс - это не объект это как раз абстракция, которая описывает объект. А объект - это уже готовый экземпляр класса.
Да-да-да. Всё как в жизни. Сделал один объект красивым, остальные идут в жертву. Например пластик. Копипаста такая линейных участков кода. Потом начинаешь вылизывать объект производства пластика, что-то третье идёт по швам. Третье переделал - другие два надо перепилить. Весь проект этим и занимаешься. Нужно правильно выбирать парадигму. Видел "шедевр" однажды как банковские процессы на ООП писали. Объект "кредит" у меня в мемах.
гыгы
Если задача плохо решается в объектной парадигме - не надо руками и ногами запихивать в неё решение))
Да, в остальную систему всё-равно придётся наверняка встраивать в виде объекта, но никто не мешает внутри сделать так, как было бы удобнее.
Какое тут ООП? Ты нарушил принцип DRY, продублировав функционал.
Чел, мы идиоты. Где картинки где динамика? Слишком мало Factorio
Я может процента три понял из этого видео. До смешного просто))))
Факториссимо идиально подходит для групировки опереденного дейсвия (в одном заводе мы делаем метал в другом электронику и так далее)
Респект за видео)
Отличный мод. Очень удобно разделять производства по ангарам и потом соединять либо последовательно, либо параллельно, в зависимости от способа распределения производств.
Объяснил, как боженька: нихуя непонятно, но этому надо следовать.
Булджать, делай видос про пчел, хорош факторио гонять
Ох - уже недоджуны начали учить. Супер - нам меньше конкурентов.
Очень интересный и понятный ролик. Круто)
В полный список идеального ООП входят 9 принципов, и даже не 4
Автор явно не понимает что такое "Инкапсулирование" и что такое "Полиморфизм"
Можно еще EventBus построить на примере поездов 😁
Только как бы то небыло, но в факторио выгоднее разносить производство по разным местам, в одном месте плавить железо, в другом медь, в другом нефть, так зачастую получаеися эффективние) (p.s. LTN сушествует)
На практике вопрос архитектуры - трейд между целями и ресурсами.
Если надо дешево и быстро, без потенциала в расширение, то зачем тратиться на что-то кроме функционального подхода ?
Если нужно сделать часть проекта доступной для работы менее квалифицированного работника, зачем много уровней абстракций ?
И тд.
Как человек с 2к часами в факторке мне больно смотреть на эти макаронины 😂
Снёс все деревья
Никто не атакует
Половина лент пустует
Вот до чего доводит ваш ооп
Все ждал когда будет запись с игры наглядная, одна болтовня
Это должны знать все, должны понимать все, не должен использовать никто.
Потому что Yagni. Если заглядывать под капот маленьким проектам то там либо какой-то мощный фрейморк или ядро, где по сути все ООП уже написано, а программист просто создает готовые экземпляры готовых классов и пользуется готовыми методами, не раскрывая и 20% фреймоврка с которым работает, потому что в его целях это просто не нужно. На гитхабе очень сложно найти репы написанные с 0 для какой-то коммерции, так как они все закрыты.
Честно говоря об ООП парадигме, она просто во многих случаях не нужна и раздувает твой код.
очень много много много много воды и пауз. В один рилз или шортз можно все уложит на 1 минуту
что за жуть. на вики более понятно всё описано.