Тик ток кинул твой видос по теме факторио Нашел фулл Никогда не интересовался программированием Но видос максимально доступный даже для моего нулевого уровня знаний в этой области Очень понравилось
Спасибо большое за ролик! Мне никогда не получалось нормально запомнить правила солид, тем не менее я всегда их придерживался. Теперь на работе я смогу гораздо лучше аргументровать то почему я пишу компоненты так как пишу и может даже смогу убедить колег писать также.
Видео не смотрел пока, но факторио прекрасно подходит для демонстрации ооп. Самый простой пример использование чертежей. Чертёж массива на 48 печек = класс, а массив печек для меди построенный это уже обьект.
@@xelax3613 Нууууууууу. Если бы мы могли обьеденять чертежи в один. Тут всё субьектино и перспективна, как в той картинке "Это правда, и это правда, а это истина". Формально в игре интерефейсы. В текущей версии 2.0 интерфейсами являются группы предметов. То есть например "Патроны для винтовки". Мы рассматриваем любой из трёх видов магазинов как обычные патроны.
Зависит от того что в этом чертеже находится. Я могу сделать чертеж и просто с сундуком и манипулятором. Чертеж это копипаста любого участка когда. Будь то функция, класс или вообще весь проект
видео очень интересное как по отношению к программированию, так и по отношению к факторио. лично мне сильно понравилось и я сильно надеюсь увидеть продолжение с разбором других трёх букв. на видео наткнулся случайно, в ленте попалось, подумал что какой-то популярный видик, а оказалось что под видео 15 комментариев. видео очень годное и интересное, жаль актива немного(
Маленький канал оказывается. Молодец, хорошо получилось. Приятно смонтированно и хорошо объяснено. Может помочь как начинающим игрокам так и программистам.
Это очень важно для проектирования программ, а для Факторки, это мелочь, которую заменяет принцип достаточности. П.с. Спроектировал 3 книги чертежей от 90 до 2700 науки в минуту. С возможностью наращивания до неразумных пределов.
ооп важно для проектирования программ?... ооп замедляет разработку, ооп отводит внимание от рабочей составляющей программы и переводит его на всякие классы, "безопаность" и то, как все это расположить. это работа наперед. вы не пробовали писать на си?
@doodocina только бейсик давным давно и делфи льва нарисовал и бросил. Рад если вы обладаете большим опытом и пониманием ситуации. Моя мысль - что в игре это не обязательно и лишь добавляет красоты и простоты.
@@doodocinaвы пробовали написать что-то сложнее прошивки для телевизора на си? Пробовали организовать работу команды хотя бы из 4-х челочек при разработке на си?
@@stepan777 я начинал с явы, написал несколько графических, физических библиотек и движков и впоследствии игр. ушел на си - почувствовал облегчение. смог портировать основную ветку движка даже на нинтендо 3дс. сейчас пишу операционку для стм32 и делаю кибердеку. организовать работу? грамотная организация работы - разделение труда. таким образом, организованная работа в команде неотличима от соло проектов. и кто я, чтобы что-то организовывать, тимлид?
По поводу открытости закрытости, я бы привел другой пример, с сити блоками, например , как только ты открыл электрические печки, но не открыл маяки, ты создаёшь ситиблок, с расчетом на маяки , и и по такому принципу по мере развития, тебе не нужно будет перелопачивать все систему а лишь в 1 блоке добавить маяки на заранее заготовленные места, и применить их ко всем ситиблокам по переплавке , или так же: сейчас у тебя сити блок производит заполненную жёлтый конвейер , но ты понимаешь, что когда будет синий, ресурсов будет меньше , и ты заранее делаешь больше печек, и получается что сейчас как таковой перегруз производства , но в дальнейшем тебе не придется все переделывать, а вообще видео очень классное, я не программист, но с полу слова понимал о чём идёт речь
Сити блоки это вообще бомба. Модули, отвечающие каждый за свою операцию. До трех входов, один выход. В нынешней версии даже заблюпринтил универсальный блок на 3 входа и 1 выход, где просто указываешь при размещении, какой продукт тебе от него нужен. Автоматизированная система станций и поездов дальше все делает сама. Берет из источников и закидывает в блок материалы, когда они нужны. И забирает и доставляет готовый продукт, когда он понадобится где-то еще. Какой--то блок не вывозит - добавил и возможно модифицировал его копию. Вуаля.
Согласен. Принцип открытости/закрытости не про "классы" рядом. А про модификацию "классов", которые уже используются. В примере получилось что добавлен новый "класс" с единой ответственностью, который позволил не модифицировать исходный.
Только недавно читал Чистую архитектуру дядюшки Боба. Он сам там явно говорит, что SRP - это не совсем про то, что компонент, класс или функция должна отвечать только за одно действие. А про то, что для изменения компонента системы должна быть только одна причина.
Да, но автор не прав в своем объяснении на примере игры. Нет никакой проблемы сделать изолированную линию которая выполняет преобразования типа A -> B -> С. Пока такая структура служит одному “actor” - все работает отлично, но если мы подключим к ней нового потребителя - тогда мощностей не хватит и возникнут сложности. Аналогия с игрой в целом не вполне уместна, фабрики в факторио уже запрограммированы, то что делает игрок - скорее архитектура приложения
Мне тут пришла гениальная мысль. Я понял, почему ситиблоки в Factorio так эффективны, по сравнению с главной шиной. Потому что это является очевидным примером реализации принципа IoC (Inversion of Control, инверсия контроля), как в Spring или JPA. По сути система поездов работает сама по себе, без вмешательства игрока. Мы ей предоставляем только "метаданные", в виде настроенных станций и поездов, а дальше всё работает само. В каком-то смысле это следующий уровень абстракции для логистики, потому что мы избавляемся и от жесткой связки между ресурсами и потребителями, а также внедряем централизованное управление ресурсами
@@SKYNET_intelдроны? Сколько нужно дронов чтобы производить 60 процесоров в секунду. Я боюсь какой нить i9-14900 от такого уйдёт в мир иной, получить хотя-бы 3ups уже роскошь а у меня только на вулкане таких 200 процов с в секунду.
@Orlangur_ модуля 3го- львиная доля , робоноги, реактор портативный турели начинка для спайдеров. 1 спайдер 1000(почти) процов я примерно делаю 1 в минуту. За час зачистки спайдеров в мир иной уходит 2-3сотни. Я сильно лоханулся полетел на Глебу первой. Гайдов не смотрел, прилетел голым, покапал, поставил реактор топлива на пару сотен часов и спокойно копал 1 науку в сек тупо забив на нё. И так я часов на 80 про неё забыл. А когда вернулся маштабироваться перед аквой, оказалась что фактор эволюции улетел за 500% и за каждый рейд на меня летит 6-7-8 больших пентоногов и мелочи с сотню, дожил до того что что в минуту 3 рейда с разных сторон в час 2.5 к турелей лазерных 5к стен, 800 трансформатров, 200 дроностанций доонов(не считал не знаю много) 7000 рем комплектов 31к ракет, 15к конверов 4го уровня, манипуляторы в ЧАС. У меня бойна как во втором старкрафте на Чаде с зергами. Потом я подумал" что я мучаюсь?", привез 6к артиллерии и 20 пушек включил через 10 минут снесли к херам всю базу под 0 вместе с реакторами.
1:41 Нет не звучит, если бы бур мог переплавлять железо и тут же делать из него шестерёнки, чтобы положить их в другой бур и уже из его переработанного железа сделать конвейеры, то цены бы им не было 3:00 Ну если ты будешь строить ТАК, то определённо 4:10 Да, это "удобнее", но в итоге производство будет громоздким, медленным и дорогим в расширении, что имеет больше шансов на задержки и проблемы, чем правильно настроенное "запутанное" производство 4:45 Копирование шаблонов это не удовольствие Вообще всё про OCP - даже в реальности вещь не очень реализуемая, потому что в итоге это приведёт к тому, что вся система сломается из-за одного элемента, который не сможет выдержать выросшую нагрузку. Я не хочу, чтобы моя фабрика была похожей на американскую банковскую систему, которая держится на DOSовских компьютерах 9:25 Вот поэтому то инженер и программист - разные профессии, потому что надо сначала продумать то, что ты собираешься делать, а не проводить диагностику когда начинаешь резать пациента. SOLID подходит не ко всем ситуациям в программировании, а к как факторио так и вообще почти полностью
Это да, но когда дело касается кода, к этому приходишь через гораздо большее количество шишек. А главное, что новички не понимают часто, зачем это ваше ООП вообще нужно и мотивация учить это дело снижается. Вот тут и приходит на помощь наглядное обьяснение на пальцах... эмм... то есть на конвеерах
Привет, познавательное видео. Но мне кажется, но или тема SRP не раскрыта в этом видео. Ты описал, как можно решить проблему фабрики, разделив категории ресурсов по конвейерам, но ты не рассказал, как ты к этому пришел. Принцип SRP, это не про то, что все должно делать что-то одно, а про то, что все должно изменяться по одной причине. В целом это нормально, когда заводы могут выполнять несколько вещей, иногда этом может быть даже выгодно и из них можно создавать отдельные модули, но как потом эти модули можно будет переиспользовать при расширении фабрики? Подобный принцип можно применять только на стадии проектирования и нарушения этого принципа исходят от недостаточного планирования и понимания предметной области. В книжке дядюшки Боба по архитектуре, он выделял акторов, которые могут ассоциировать с одним вариантом использования. В нашу обязанность, как архитектора, входят определение этих акторов и выделение связей ассоциации. Теперь к фабрикам: в нашем случае, этими акторами являются другие фабрики, которым нужны ресурсы соответствующего типа. И представь себе ситуацию, у нас есть наша мультифабрика, хорошо. Но мы хотим построить еще одну. Для этого мы должны переделать нашу основную фабрику для того, чтобы мы смогли наш промежуточный ресурс передать другой, что может быть не позволительно в плане пространства и придется страдать, и так для каждого нового актора(фабрики), таким образом мы нарушаем SRP. И тут уже на сцену должен выйти ты и сказать, что нужно разделить фабрики и ленты по категориям, где каждая лента является отдельным вариантом использования, для каждого нашего нового актора. И теперь наша фабрика промежуточночных(уже нет) ресурсов изменяется только по одной причине - увеличение объемов производства. Ты можешь сказать мне, что это очень похоже на обеспечение принципов OCP и верно. Я считаю, что некоторыми принципами SOLID можно обеспечить и другие принципы, мы бы могли также через принципы OCP и обеспечить SRP, и, наверное, минуя стадию проектирования. Так что это не совсем верно, ограничить применение SRP только для категорий и конвейеров. Это может ввести в заблуждение зрителя, что один объект должен делать только одну вещь и одно полезное действие, что неправда и прожет привести к странным последствиям. Спасибо, что дочитал, я буду рад услышать что-нибудь с чем ты не согласен.
Привет! Спасибо за детальный и очень глубокий комментарий! Я ценю, что ты нашел время так подробно описать свои мысли, и действительно, многие аспекты, которые ты затронул, важны для полного понимания SRP. Ты абсолютно прав, что SRP - это не про ограничение "одна вещь - одно действие", а про то, чтобы у каждого компонента была одна причина для изменения. Это важный момент, и, возможно, я слишком упростил его в видео. Ты также подметил интересный подход к выделению акторов - отличный пример из книги дядюшки Боба, который помогает лучше понять, как правильно определять границы ответственности. Однако есть пара моментов, где, на мой взгляд, может возникнуть небольшое заблуждение. Например, идея о том, что каждый конвейер или модуль должен быть уникальным под каждую фабрику. Конечно, это хороший принцип, если мы говорим о модульности и масштабируемости, но иногда подобное "раздробление" может привести к избыточной сложности и затруднению в управлении - особенно на ранних стадиях проекта, когда система еще не достигла нужного уровня зрелости. Важно балансировать между модульностью и сложностью, и иногда создание единой мультифабрики может быть оправданным компромиссом для более легкого расширения в будущем, даже если оно нарушает классическое определение SRP. Все сводится к тому, как хорошо мы понимаем будущие требования и можем ли мы предугадать их изменения. Ты также правильно подметил, что некоторые принципы, такие как SRP и OCP, часто переплетаются и даже взаимно обеспечивают друг друга. Это показывает, что архитектурные принципы не существуют в изоляции, а работают вместе, чтобы создавать более гибкие и поддерживаемые системы. Еще раз спасибо за твой комментарий! Он действительно добавляет глубины в обсуждение, и я буду рад услышать твои мысли по поводу баланса между модульностью и сложностью на ранних стадиях разработки.
@@Just-York Привет, спасибо за развернутый ответ! Про баланс между модульностью и сложностью. Когда мы строим фабрику, мы всегда должны опираться на какие-то цели, которые мы хотим выполнить. Архитектура должна кричать, как говорил Дядюшка боб. Если для текущих наших целей в игре лучше всего подойдет единая мультифабрика, например по вопросам её питания и остаткам ресурсов, то будет мудрее построить мультифабрику, чтобы быстро получить много ресурсов или достичь нужных целей. Потом у нас появляются новые цели и мы следовательно меняем нашу архитектуру, чтобы нам было проще добиться уже их. Разделение проекта на модули, это всегда компромисс, так как мы еще должны каким-то образом налаживать связи между этими несвязанными модулями, и у нас появляется еще один аспект, который мы должны контролировать. Эта связь в нашему случае является способом дислокации ресурсов и нам нужно будет хорошо подумать, как эту систему лучше все построить. Но мы можем миновать этот аспект или снизить нагрузку на связи, если мы объединим некоторые фабрики или модули вместе. И вот мой конкретный ответ по поводу баланса на ранних стадиях игры: Нам нужно задать себе два вопроса: - Для чего нам нужна эта связь? - Можем ли мы её себе позволить? Во второй вопрос еще входит потенциальная цена, которую мы готовы отдать за связь, например скорость передвижения ресурсов и т.д. Если мы можем ответить на эти вопросы, то значит нам стоит сделать эти связи и выделить модули, учитывая данные связи.
Все "парадигмы программирования" - пустая религия. Нет никаких принципов солид и ООП нет. Это мифы передающиеся из уст в уста. И абсолютно укаждого проэкта свой собственный ООП и так далее. Даже если правила этих парадигм четко расписать, каждый будет их реальзовывать по своему.
Ну принцип открытости, а точнее закрытости мне всегда не нравился - зачем от меня что-то скрывают? Почему просто не обзывать методы и атрибуты через нижние подчеркивания, т.к. это делает питон, при этом дать возможность что-то менять. Типа ты можешь изменить там все, или запускать скрытые методы по своему, если тебе это надо, но если что-то сломается - виноват ты сам, т.к. тебя заранее как-бы предупреждали. Это может показаться странным, но иногда использование скрытых полей просто необходимо, мне это особенно нужно в машинном обучении в torch или transformers.
Слишком много слов и мало примеров в игре. Почти весь видеоряд - простой филлер. Почти вся информация доносится исключительно словами. Примеров, графиков, рисунков нет. Посмотри как fed1s play рассказал про ооп на примере факторио, вот он сделал хорошо, наглядно и понятно. Там практически весь видеоряд - это презентация с очевидными примерами. При этом у тебя слишком много лишних слов. На мой взгляд, нужно потратить больше времени на структуризацию информации и оптимизацию ее подачи. Удалить всю воду, и перенести больше информации в визуальный вид. Больше примеров и рисунков, меньше трындежа. Ставлю лайк, и жду следующее видео. Идея классная, но нужно еще поработать. Очень надеюсь, что моя критика не сильно тебя расстроит, и я увижу следующие видео, которые будут выше всяческих похвал.
Спасибо, приму к сведению!) Можешь глянуть предыдущий ролик про ооп, там делал больше вставок с игры. В общем пробую разные форматы, чтобы понять что лучше)
Даааа. Это всё слишком очевидно чтоб всё это так витиевато проговаривать. Если принимать это всё в контексте программирования, а не факторки - программировать и модифицировать что то становится более удобным, но и программы становятся более объёмными и тяжеловесными. Я вот вспоминаю лаунчер для игр Близзард. Казалось бы - маленький программа для запуска всего нескольких игр, но весит условно гиг, и тормозит так что у меня в своё время Крайзис так не тормозил. Я вот допустим прощёлкиваю вкладки каждой игры, от первой до последней, 6 штук, но пока прогрузится каждая - это более минуты занимало. Вот почему так?.. Почему разрабы не хотят в оптимизацию и быстродействие?..
Так лол, а вы никогда не замечали что факторио это и есть прогамммирование? Моды - библиотеки, city block - модульная архитектура, главная шина - redux, начало проекта такое же тяжкое как и начало завода, там очень много переплетений
Мой вам совет - не идите в программирование, просто играйте в свое фактрио. Ну и если все же захотите поиграть мультиплеер, то пользуйтесь чуть-чуть логикой и здравым смыслом, а не несите говнофабрики в массы, которые останавливают сервера и вынуждают тех, кто был там до вас сваливать, лишь бы не иметь с вами дела. SRP это как калькулятор - просто, понятно, можно пользоваться. А вот нахрена процессоры делать долгое время не понимали - какая-то сложная и дорогая фигня, которая много всего всякого умеет делать лишьнего. Потом процессор вставили в телефон, в машинку стиральную, в принтер, в домофон, роутер, в компьютер, и даже в мышь и в клавиатуру. А потом и калькуляторы стали делать на базе процессоров общего назначения, а не специфичных конкретно для них. И в факторио можно сделать оптимизированные несколько фабрик, типа этап 1, этап 2, этап 3, а потом копипастить. А вот SRP и т.д. - это про спагетификацию и технический долг. Потом приходят на работу и сидят там "наслаждаются процессом", а мне потом работать за троих, чтобы был результат и не увилили всю команду.
Только общие фразы из разряда "делайте хорошо, а плохо не делайте" 15 минут воды ... из которых ясно что в факторио автор толком не играл и лишь примерно представляет себе что это такое ... и программирует скорее всего так же
М ...да ... даже бы в башку не пришо ООП в таком представлении рассматривать, но увы лично мне кажется что это очень не информативно, мне кажется , самый яркий пример отличия преимуществ ООП и "КЛСССАОВ" это инжекция, вот лично как человек начавший с машинного кода, не вижу никаких проблем или иных преимуществ ООП, а адеж могу назвать тонны минусов, кроме инжекции, это да это просто легенда, когда ты можешь взять готовый класс, и изменить в нём только ту часть которая тебе не обходима для какого то извращения, при этом не трогая и даже не вдаваясь в то как работает остальная начинка.
Если считать factorio за программирование, то буквально на твою программу нападают BUGS🧐
Начал изучать программирование, узнал о факторио, бросил программирование, ля
Бох отвадил
Да, Факторио, она такая...
Мало объяснения, на счет остальных принципов. Еще целых 3 принципа не объяснено
8 месяцев назад? Мужик, Ты нам нужен
@@IshuckShow уговорил) на этой неделе сделаю)
@@Just-York Я проверю
@@Just-York только для начала нужно ещё немножко порезвиться в space age😅
@ да, это уже в процессе))
Чел, ты гений, очень наглядно получилось. Жду продолжение!!!
я хоть и так знаю про это в программировании, но мне всё равно стало интересно это посмотреть, прикольный подход к рассказу какой-либо информации
Спасибо автор , очень полезный , а главное интересный ролик , при том что я не программист и никогда не играл в факторию ))
Хороший канал, удивлен что мало подписалось людей. Удачи в развитии. Подача топ
Тик ток кинул твой видос по теме факторио
Нашел фулл
Никогда не интересовался программированием
Но видос максимально доступный даже для моего нулевого уровня знаний в этой области
Очень понравилось
Перед собесом на сеьнора наткнулся на видос, отлично объясняешь :)
Через факторио очень интересно смотреть, гениально, спасибо, продолжай развиваться
Спасибо большое за ролик! Мне никогда не получалось нормально запомнить правила солид, тем не менее я всегда их придерживался. Теперь на работе я смогу гораздо лучше аргументровать то почему я пишу компоненты так как пишу и может даже смогу убедить колег писать также.
Очень годно, сложный концепт в визуальном представлении, нужно продолжение, контент огонь!!!
Видео не смотрел пока, но факторио прекрасно подходит для демонстрации ооп.
Самый простой пример использование чертежей. Чертёж массива на 48 печек = класс, а массив печек для меди построенный это уже обьект.
чертеж это интерфейс как мне кажется
@@xelax3613 Нууууууууу. Если бы мы могли обьеденять чертежи в один. Тут всё субьектино и перспективна, как в той картинке "Это правда, и это правда, а это истина".
Формально в игре интерефейсы. В текущей версии 2.0 интерфейсами являются группы предметов. То есть например "Патроны для винтовки". Мы рассматриваем любой из трёх видов магазинов как обычные патроны.
Зависит от того что в этом чертеже находится. Я могу сделать чертеж и просто с сундуком и манипулятором.
Чертеж это копипаста любого участка когда. Будь то функция, класс или вообще весь проект
видео очень интересное как по отношению к программированию, так и по отношению к факторио. лично мне сильно понравилось и я сильно надеюсь увидеть продолжение с разбором других трёх букв. на видео наткнулся случайно, в ленте попалось, подумал что какой-то популярный видик, а оказалось что под видео 15 комментариев. видео очень годное и интересное, жаль актива немного(
Благодарю за поддержку, обязательно будет продолжение!
Прошу больше видео и можно немного примеров из факторио и из кода
4:49 конвейер не повернут в балансер)
Маленький канал оказывается. Молодец, хорошо получилось. Приятно смонтированно и хорошо объяснено. Может помочь как начинающим игрокам так и программистам.
Это очень важно для проектирования программ, а для Факторки, это мелочь, которую заменяет принцип достаточности.
П.с. Спроектировал 3 книги чертежей от 90 до 2700 науки в минуту.
С возможностью наращивания до неразумных пределов.
ооп важно для проектирования программ?...
ооп замедляет разработку, ооп отводит внимание от рабочей составляющей программы и переводит его на всякие классы, "безопаность" и то, как все это расположить. это работа наперед.
вы не пробовали писать на си?
@doodocina только бейсик давным давно и делфи льва нарисовал и бросил.
Рад если вы обладаете большим опытом и пониманием ситуации.
Моя мысль - что в игре это не обязательно и лишь добавляет красоты и простоты.
@@doodocinaвы пробовали написать что-то сложнее прошивки для телевизора на си? Пробовали организовать работу команды хотя бы из 4-х челочек при разработке на си?
@@stepan777 я начинал с явы, написал несколько графических, физических библиотек и движков и впоследствии игр. ушел на си - почувствовал облегчение. смог портировать основную ветку движка даже на нинтендо 3дс. сейчас пишу операционку для стм32 и делаю кибердеку.
организовать работу? грамотная организация работы - разделение труда. таким образом, организованная работа в команде неотличима от соло проектов. и кто я, чтобы что-то организовывать, тимлид?
Автор, классный ролик!
По поводу открытости закрытости, я бы привел другой пример, с сити блоками, например , как только ты открыл электрические печки, но не открыл маяки, ты создаёшь ситиблок, с расчетом на маяки , и и по такому принципу по мере развития, тебе не нужно будет перелопачивать все систему а лишь в 1 блоке добавить маяки на заранее заготовленные места, и применить их ко всем ситиблокам по переплавке , или так же: сейчас у тебя сити блок производит заполненную жёлтый конвейер , но ты понимаешь, что когда будет синий, ресурсов будет меньше , и ты заранее делаешь больше печек, и получается что сейчас как таковой перегруз производства , но в дальнейшем тебе не придется все переделывать, а вообще видео очень классное, я не программист, но с полу слова понимал о чём идёт речь
Сити блоки это вообще бомба. Модули, отвечающие каждый за свою операцию. До трех входов, один выход. В нынешней версии даже заблюпринтил универсальный блок на 3 входа и 1 выход, где просто указываешь при размещении, какой продукт тебе от него нужен. Автоматизированная система станций и поездов дальше все делает сама. Берет из источников и закидывает в блок материалы, когда они нужны. И забирает и доставляет готовый продукт, когда он понадобится где-то еще. Какой--то блок не вывозит - добавил и возможно модифицировал его копию. Вуаля.
@@FreakinGeniousподелись чертежами
Спасибо за контент, жду с нетерпением следующую часть
7:20. Больше похоже не на расширение сущности, а создание новой. В чем разница вместо созданием нового и расширением старого?
Согласен. Принцип открытости/закрытости не про "классы" рядом. А про модификацию "классов", которые уже используются. В примере получилось что добавлен новый "класс" с единой ответственностью, который позволил не модифицировать исходный.
Сам же сказал, сначала все идет хорошо. А когда начинает идти плохо - просто масштабируешь :D
большое спасибо за видео, очень интересно смотреть!
Только недавно читал Чистую архитектуру дядюшки Боба. Он сам там явно говорит, что SRP - это не совсем про то, что компонент, класс или функция должна отвечать только за одно действие. А про то, что для изменения компонента системы должна быть только одна причина.
Ну и как следствие единая ответственность
@ да всё так. 👍
Да, но автор не прав в своем объяснении на примере игры. Нет никакой проблемы сделать изолированную линию которая выполняет преобразования типа A -> B -> С. Пока такая структура служит одному “actor” - все работает отлично, но если мы подключим к ней нового потребителя - тогда мощностей не хватит и возникнут сложности.
Аналогия с игрой в целом не вполне уместна, фабрики в факторио уже запрограммированы, то что делает игрок - скорее архитектура приложения
Шикарное видео, даль что мало откликов для автора. Смотрю контент на этом остановился.
Дядь, ты гений
Удачи с L и I, с D понятно - главная шина.
Ещё 8 лайков, и новое видиво, ура)
Гениальное видео!
Прошу больше наглядности, т.к. пример с энергией умозрителен, ставлю SLR на аккуме, для перевода паровой генерации в резерв, а сие уже - модификация.
Мне тут пришла гениальная мысль.
Я понял, почему ситиблоки в Factorio так эффективны, по сравнению с главной шиной. Потому что это является очевидным примером реализации принципа IoC (Inversion of Control, инверсия контроля), как в Spring или JPA.
По сути система поездов работает сама по себе, без вмешательства игрока. Мы ей предоставляем только "метаданные", в виде настроенных станций и поездов, а дальше всё работает само.
В каком-то смысле это следующий уровень абстракции для логистики, потому что мы избавляемся и от жесткой связки между ресурсами и потребителями, а также внедряем централизованное управление ресурсами
@@R0MaNbI4- все верно
А молл на дронах ещё более эфективный.
@@SKYNET_intelдроны? Сколько нужно дронов чтобы производить 60 процесоров в секунду. Я боюсь какой нить i9-14900 от такого уйдёт в мир иной, получить хотя-бы 3ups уже роскошь а у меня только на вулкане таких 200 процов с в секунду.
@@РоманМаслянчук А зачем тебе 60 процессоров в секунду в молле?
@Orlangur_ модуля 3го- львиная доля , робоноги, реактор портативный турели начинка для спайдеров. 1 спайдер 1000(почти) процов я примерно делаю 1 в минуту. За час зачистки спайдеров в мир иной уходит 2-3сотни. Я сильно лоханулся полетел на Глебу первой. Гайдов не смотрел, прилетел голым, покапал, поставил реактор топлива на пару сотен часов и спокойно копал 1 науку в сек тупо забив на нё. И так я часов на 80 про неё забыл. А когда вернулся маштабироваться перед аквой, оказалась что фактор эволюции улетел за 500% и за каждый рейд на меня летит 6-7-8 больших пентоногов и мелочи с сотню, дожил до того что что в минуту 3 рейда с разных сторон в час 2.5 к турелей лазерных 5к стен, 800 трансформатров, 200 дроностанций доонов(не считал не знаю много) 7000 рем комплектов 31к ракет, 15к конверов 4го уровня, манипуляторы в ЧАС. У меня бойна как во втором старкрафте на Чаде с зергами. Потом я подумал" что я мучаюсь?", привез 6к артиллерии и 20 пушек включил через 10 минут снесли к херам всю базу под 0 вместе с реакторами.
SRP - надо чтоб всё выполняло одну конкретную задачу
также SRP - 4:57 - по одному конвейеру едет и железная руда, и камень
НЕ ПОРЯДОК!)
Конвеер выполняет роль DTO, который переносит данные из одного места в другое. Поэтому в этом случае это допустимо
Давай ещё!
Благодарю! Приятно слушать!
Автор, пожалуйста, продолжи серию роликов -_-
круто, но имхо не хватает аналитики на каких моделях и методах всё таки построены принципы solid и как их эти модели экстраполировать на новые системы
1:41 Нет не звучит, если бы бур мог переплавлять железо и тут же делать из него шестерёнки, чтобы положить их в другой бур и уже из его переработанного железа сделать конвейеры, то цены бы им не было
3:00 Ну если ты будешь строить ТАК, то определённо
4:10 Да, это "удобнее", но в итоге производство будет громоздким, медленным и дорогим в расширении, что имеет больше шансов на задержки и проблемы, чем правильно настроенное "запутанное" производство
4:45 Копирование шаблонов это не удовольствие
Вообще всё про OCP - даже в реальности вещь не очень реализуемая, потому что в итоге это приведёт к тому, что вся система сломается из-за одного элемента, который не сможет выдержать выросшую нагрузку. Я не хочу, чтобы моя фабрика была похожей на американскую банковскую систему, которая держится на DOSовских компьютерах
9:25 Вот поэтому то инженер и программист - разные профессии, потому что надо сначала продумать то, что ты собираешься делать, а не проводить диагностику когда начинаешь резать пациента.
SOLID подходит не ко всем ситуациям в программировании, а к как факторио так и вообще почти полностью
мужик, хорош
Snake are You Alright? Snake! Snaaake!
Лайк за факторио!)
блин тысячу лайков так и не набрал видос :( жаль, я хотел увидеть продолжение
@@Virus-td9nc будет, уже в процессе)
Интересно что многое из этого делается интуитивно
Это да, но когда дело касается кода, к этому приходишь через гораздо большее количество шишек. А главное, что новички не понимают часто, зачем это ваше ООП вообще нужно и мотивация учить это дело снижается. Вот тут и приходит на помощь наглядное обьяснение на пальцах... эмм... то есть на конвеерах
Когда продолжение?)
Сколько текста написано гптшкой?
Удивительно!!!!
4:35 - 4:42
Вот конкретный пример и объяснение того, почему SOLID просто нахрен не сдался при написании маленьких программ, и только вредит им.
Думаю, можно понять видео, только если ты уже понимаешь ооп и солид
и в этом случае ты с видео не сможешь согласиться на 100% XD
Привет, познавательное видео. Но мне кажется, но или тема SRP не раскрыта в этом видео. Ты описал, как можно решить проблему фабрики, разделив категории ресурсов по конвейерам, но ты не рассказал, как ты к этому пришел. Принцип SRP, это не про то, что все должно делать что-то одно, а про то, что все должно изменяться по одной причине. В целом это нормально, когда заводы могут выполнять несколько вещей, иногда этом может быть даже выгодно и из них можно создавать отдельные модули, но как потом эти модули можно будет переиспользовать при расширении фабрики? Подобный принцип можно применять только на стадии проектирования и нарушения этого принципа исходят от недостаточного планирования и понимания предметной области. В книжке дядюшки Боба по архитектуре, он выделял акторов, которые могут ассоциировать с одним вариантом использования. В нашу обязанность, как архитектора, входят определение этих акторов и выделение связей ассоциации. Теперь к фабрикам: в нашем случае, этими акторами являются другие фабрики, которым нужны ресурсы соответствующего типа. И представь себе ситуацию, у нас есть наша мультифабрика, хорошо. Но мы хотим построить еще одну. Для этого мы должны переделать нашу основную фабрику для того, чтобы мы смогли наш промежуточный ресурс передать другой, что может быть не позволительно в плане пространства и придется страдать, и так для каждого нового актора(фабрики), таким образом мы нарушаем SRP. И тут уже на сцену должен выйти ты и сказать, что нужно разделить фабрики и ленты по категориям, где каждая лента является отдельным вариантом использования, для каждого нашего нового актора. И теперь наша фабрика промежуточночных(уже нет) ресурсов изменяется только по одной причине - увеличение объемов производства. Ты можешь сказать мне, что это очень похоже на обеспечение принципов OCP и верно. Я считаю, что некоторыми принципами SOLID можно обеспечить и другие принципы, мы бы могли также через принципы OCP и обеспечить SRP, и, наверное, минуя стадию проектирования.
Так что это не совсем верно, ограничить применение SRP только для категорий и конвейеров. Это может ввести в заблуждение зрителя, что один объект должен делать только одну вещь и одно полезное действие, что неправда и прожет привести к странным последствиям.
Спасибо, что дочитал, я буду рад услышать что-нибудь с чем ты не согласен.
Привет! Спасибо за детальный и очень глубокий комментарий! Я ценю, что ты нашел время так подробно описать свои мысли, и действительно, многие аспекты, которые ты затронул, важны для полного понимания SRP.
Ты абсолютно прав, что SRP - это не про ограничение "одна вещь - одно действие", а про то, чтобы у каждого компонента была одна причина для изменения. Это важный момент, и, возможно, я слишком упростил его в видео. Ты также подметил интересный подход к выделению акторов - отличный пример из книги дядюшки Боба, который помогает лучше понять, как правильно определять границы ответственности.
Однако есть пара моментов, где, на мой взгляд, может возникнуть небольшое заблуждение. Например, идея о том, что каждый конвейер или модуль должен быть уникальным под каждую фабрику. Конечно, это хороший принцип, если мы говорим о модульности и масштабируемости, но иногда подобное "раздробление" может привести к избыточной сложности и затруднению в управлении - особенно на ранних стадиях проекта, когда система еще не достигла нужного уровня зрелости.
Важно балансировать между модульностью и сложностью, и иногда создание единой мультифабрики может быть оправданным компромиссом для более легкого расширения в будущем, даже если оно нарушает классическое определение SRP. Все сводится к тому, как хорошо мы понимаем будущие требования и можем ли мы предугадать их изменения.
Ты также правильно подметил, что некоторые принципы, такие как SRP и OCP, часто переплетаются и даже взаимно обеспечивают друг друга. Это показывает, что архитектурные принципы не существуют в изоляции, а работают вместе, чтобы создавать более гибкие и поддерживаемые системы.
Еще раз спасибо за твой комментарий! Он действительно добавляет глубины в обсуждение, и я буду рад услышать твои мысли по поводу баланса между модульностью и сложностью на ранних стадиях разработки.
@@Just-York Привет, спасибо за развернутый ответ! Про баланс между модульностью и сложностью. Когда мы строим фабрику, мы всегда должны опираться на какие-то цели, которые мы хотим выполнить. Архитектура должна кричать, как говорил Дядюшка боб. Если для текущих наших целей в игре лучше всего подойдет единая мультифабрика, например по вопросам её питания и остаткам ресурсов, то будет мудрее построить мультифабрику, чтобы быстро получить много ресурсов или достичь нужных целей. Потом у нас появляются новые цели и мы следовательно меняем нашу архитектуру, чтобы нам было проще добиться уже их.
Разделение проекта на модули, это всегда компромисс, так как мы еще должны каким-то образом налаживать связи между этими несвязанными модулями, и у нас появляется еще один аспект, который мы должны контролировать. Эта связь в нашему случае является способом дислокации ресурсов и нам нужно будет хорошо подумать, как эту систему лучше все построить. Но мы можем миновать этот аспект или снизить нагрузку на связи, если мы объединим некоторые фабрики или модули вместе.
И вот мой конкретный ответ по поводу баланса на ранних стадиях игры:
Нам нужно задать себе два вопроса:
- Для чего нам нужна эта связь?
- Можем ли мы её себе позволить?
Во второй вопрос еще входит потенциальная цена, которую мы готовы отдать за связь, например скорость передвижения ресурсов и т.д.
Если мы можем ответить на эти вопросы, то значит нам стоит сделать эти связи и выделить модули, учитывая данные связи.
Все "парадигмы программирования" - пустая религия.
Нет никаких принципов солид и ООП нет. Это мифы передающиеся из уст в уста.
И абсолютно укаждого проэкта свой собственный ООП и так далее.
Даже если правила этих парадигм четко расписать, каждый будет их реальзовывать по своему.
Я знаю только ООСД
Стоит ли изучать факторио чтобы стать программистом ? :)
Через месяц у меня экзамен по ООП. Думаю, я сдам😁
интересный видос, жаль что бросил канал
Ну принцип открытости, а точнее закрытости мне всегда не нравился - зачем от меня что-то скрывают? Почему просто не обзывать методы и атрибуты через нижние подчеркивания, т.к. это делает питон, при этом дать возможность что-то менять. Типа ты можешь изменить там все, или запускать скрытые методы по своему, если тебе это надо, но если что-то сломается - виноват ты сам, т.к. тебя заранее как-бы предупреждали. Это может показаться странным, но иногда использование скрытых полей просто необходимо, мне это особенно нужно в машинном обучении в torch или transformers.
Слишком много слов и мало примеров в игре. Почти весь видеоряд - простой филлер. Почти вся информация доносится исключительно словами. Примеров, графиков, рисунков нет. Посмотри как fed1s play рассказал про ооп на примере факторио, вот он сделал хорошо, наглядно и понятно. Там практически весь видеоряд - это презентация с очевидными примерами. При этом у тебя слишком много лишних слов.
На мой взгляд, нужно потратить больше времени на структуризацию информации и оптимизацию ее подачи. Удалить всю воду, и перенести больше информации в визуальный вид. Больше примеров и рисунков, меньше трындежа. Ставлю лайк, и жду следующее видео. Идея классная, но нужно еще поработать. Очень надеюсь, что моя критика не сильно тебя расстроит, и я увижу следующие видео, которые будут выше всяческих похвал.
Спасибо, приму к сведению!) Можешь глянуть предыдущий ролик про ооп, там делал больше вставок с игры. В общем пробую разные форматы, чтобы понять что лучше)
это круто
Принцип единственной ответственности 🤔.
Я думал это очевидно. А оказалось что нет . Людям этот принцип приходится разъяснять 😥
Даааа. Это всё слишком очевидно чтоб всё это так витиевато проговаривать.
Если принимать это всё в контексте программирования, а не факторки - программировать и модифицировать что то становится более удобным, но и программы становятся более объёмными и тяжеловесными.
Я вот вспоминаю лаунчер для игр Близзард. Казалось бы - маленький программа для запуска всего нескольких игр, но весит условно гиг, и тормозит так что у меня в своё время Крайзис так не тормозил. Я вот допустим прощёлкиваю вкладки каждой игры, от первой до последней, 6 штук, но пока прогрузится каждая - это более минуты занимало. Вот почему так?.. Почему разрабы не хотят в оптимизацию и быстродействие?..
А где LID?
Суши белтами надо уметь пользоваться и там логика нужна чтобы ничего не переполнилось
Так лол, а вы никогда не замечали что факторио это и есть прогамммирование? Моды - библиотеки, city block - модульная архитектура, главная шина - redux, начало проекта такое же тяжкое как и начало завода, там очень много переплетений
норм, но както затянуто
Ты секси бетмен тутутутту
Факторио и программирование это как море и морские свинки.. Почему столько людей пытаются натянуть сову на глобус?)
Потому что это буквально визуальное программирование. Говорю как программист с 10-тилетним стажем
Как по мне, видео будет понятно тем, что понимает SOLID и Factorio.
Еще не набрали 1000 лайков....
Чел буквально читает сырой текст из gpt
Мой вам совет - не идите в программирование, просто играйте в свое фактрио. Ну и если все же захотите поиграть мультиплеер, то пользуйтесь чуть-чуть логикой и здравым смыслом, а не несите говнофабрики в массы, которые останавливают сервера и вынуждают тех, кто был там до вас сваливать, лишь бы не иметь с вами дела.
SRP это как калькулятор - просто, понятно, можно пользоваться. А вот нахрена процессоры делать долгое время не понимали - какая-то сложная и дорогая фигня, которая много всего всякого умеет делать лишьнего. Потом процессор вставили в телефон, в машинку стиральную, в принтер, в домофон, роутер, в компьютер, и даже в мышь и в клавиатуру. А потом и калькуляторы стали делать на базе процессоров общего назначения, а не специфичных конкретно для них. И в факторио можно сделать оптимизированные несколько фабрик, типа этап 1, этап 2, этап 3, а потом копипастить. А вот SRP и т.д. - это про спагетификацию и технический долг.
Потом приходят на работу и сидят там "наслаждаются процессом", а мне потом работать за троих, чтобы был результат и не увилили всю команду.
Так вот в чем сольид
Не ну заключении как то слишком много кринжа навалил)
Свали
Жаль, что забросили
Это все элементарщина и ломается сразу же, как только ты упираешься в ограничение какого-либо ресурса (включая время и пространство)
Общие слова без конкретики. Ни в фактором, ни в программировании.
Гуляй
Чето меня от факторио мутит
Только общие фразы из разряда "делайте хорошо, а плохо не делайте"
15 минут воды
... из которых ясно что в факторио автор толком не играл и лишь примерно представляет себе что это такое
... и программирует скорее всего так же
автор рефлексирует и это норм)
М ...да ... даже бы в башку не пришо ООП в таком представлении рассматривать, но увы лично мне кажется что это очень не информативно, мне кажется , самый яркий пример отличия преимуществ ООП и "КЛСССАОВ" это инжекция, вот лично как человек начавший с машинного кода, не вижу никаких проблем или иных преимуществ ООП, а адеж могу назвать тонны минусов, кроме инжекции, это да это просто легенда, когда ты можешь взять готовый класс, и изменить в нём только ту часть которая тебе не обходима для какого то извращения, при этом не трогая и даже не вдаваясь в то как работает остальная начинка.
Ну, и где?????