Видео

А иногда даже не кривой)

Увы, это не хрущёвка :P

Уже есть) t.me/UnitistNotes

Ну тут-то палочки таки отличаются :D

Далее по видео я показал, куда Observer эволюционировал - на 12:20 можете посмотреть :) Там компактнее получилось

Спасибо) ​@@sergeykazantsev1655

Если нужен "голый" наблюдатель (не через events), то с С#8 мы можем дать в интерфейс типовую реализацию методов. Вещь сомнительная, но если следить за тем, чтобы не просачивалась конкретика в интерфейс, то это можно сделать так. Методы здесь работают только с тем, что есть внутри интерфейса, инкапсуляция не нарушается, но с явной реализацией в интерфейсах нужно быть крайне осторожным. public interface ISubject { ICollection<IObserver> Observers { get; init; } void Attach(IObserver observer) { if(!Observers.Contains(observer)) Observers.Add(observer); } void Detach(IObserver observer) { if (Observers.Contains(observer)) Observers.Remove(observer); } void Notify(); } UPD: Notify все таки лучше оставить нереализованным.

Я потихоньку запустил канал сообщества, там был вопрос на эту тему t.me/UnitistNotes Не то, чтобы там прям много полезной инфы - но возможно что-то полезное найдете)

На моём опыте были проблемы с порядком уведомления подписчиков, они же race-conditions. Когда две системы подписаны на одно и то-же событие, но необходимо чтобы первая система среагировала раньше второй. В целом, хорошо написанные сигнальные шины позволяют это сделать.

@@sergeykazantsev1655 ну вот, Вы опять протаскиваете зависимость. На шине все равны, там нет первых, вторых или десятых. А "хорошо написанные сигнальные шины" -- это уже расширение, а не наследование :)

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

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

Я ваш аргумент про точки зрения понимаю, Но я считаю что если человек на каком-то деле съел собаку, а всякие Кнуты, Рихтеры, Фаулеры и прочие авторы которые переиздают одну и ту же книгу в течение 20 лет, редактируют, улучшают ее, дискутируют на форумах и тд - это не просто вкусовое мнение - это занесенный на бумагу многолетний опыт, как минимум выслушать стоит. А так если спорить - надо тогда на факты выводить) Почему избегание копирования побочный эффект? Почему именно абстрагирование и возможность отделение абстракции от деталей важнее? А если главное в наследовании это отношение между абстрактным и детальным - то зачем тогда принцип Абстракция - разве они не одно и то же тогда объясняют? Все равно конечно на вкусовщину и личный опыт сойдемся - но мало ли

@@sergeykazantsev1655 книги конечно читать надо :). Да, это материализованный опыт. Но всего лишь опыт. И если выводы противоречат вашему опыту, то почему бы не поспорить? Да, в наследовании отношение абстрактный-детальный важнее копирования. Потому что это фундамент ООП, причина для наследования, база для полиморфизма. А то, что на этом можно строки кода экономить -- это побочный эффект. Однако зримый эффект, вот на нём и фокусируются. Вы себе вопрос задайте, как часто причиной наследования была необходимость избежать копирования? Или все же чаще Вы иерархию абстракций строили. Судя по википедии принцип абстракции вообще к наследованию не относится. Он призывает избегать дублирования кода "путем использования абстракций, предоставляемых языком программирования или библиотеками программного обеспечения". Так что абстракции в принципе абстракции, это несколько иное понятие, нежели абстракции в наследовании ООП. Примечание. Я в этом топике только Ваши комментарии вижу почему-то.

Я ваши ответы не удаляю, если что) Для меня в наследовании важно расширение: написать абстрактное ядро, и в потомках уже добавлять уникальное мясцо. Я частенько огребал последствий от дублированного в нескольких местах кода, и наоборот, получал много эстетического удовольствия, когда какую нибудь логику окошек загнал в базовый класс, написал ее в одном месте и забыл. И когда нужно поменять поведение, мне достаточно менять его в одном месте. Создание ядра с логикой, и наращивание другой логики для потомков - вот что я вижу главной частью наследования. И такое наращивание возможно благодаря копированию. Как-то так

А в итоге мы приходим в высшей абстракции - компьютер.

А компьютер ноутбук, десктоп, планшет, телефон??? Мироустройство матьегоети

Высшая абстракция это момент большого взрыва )

Фабрики создают объекты, а сервис локатор предоставляет доступ к уже созданным)

Вот она, сила ООП в своей красе...

Ну и получается что мы берём результат фабрики - ивент. И с помощью билдера строим поэтапно оборачивая его в декораторы до момента пока не будет готова отправить постзапрос с сообщением в канал. И сверху слои хендлеров ответов что нам сказал рассыльщик, обработки ошибок, иретрай упавших. Слоёный пирог, или лук, не знаю с чем ассоциировать. Как по мне пирог приятнее для запоминания.

Рассылка это про взаимодействие между классами. Здесь же(и в абстрактной фабрике) речь про то где порождать и как порождать объекты

Порождать объекты с заданиями для очереди. Генератор задач для очереди? С которыми работаем потом каждым отдельно в другом месте как с пирожками.

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

Тут зависит от фирмы, список вопросов может сильно меняться. Большинство спрашивает про принципы ООП, SOLID, структуры данных, про Unity(Monobehaviour loop, rigidbody, collider, particleSystem, корутины), просят на бумажке или на пальцах описать 3 паттерна проектирования на твой выбор. Ну и хорошо бы про C# что-то ответить(Что такое интерфейс, в чем разница между структурой и классом и тд)

@@sergeykazantsev1655 Спасибо, значит я готов)

есть тг канал сообщества t.me/UnitistNotes был там опрос - что спрашивают джунов и мидлов. Можете туда после собеса отписаться - что спрашивали. Может это будет полезно остальным

Здравствуйте, да, Command с MVVM в геймдеве можно сочетать, как я понимаю он где-то в ViewModel должен находится Насчёт простейших графических оконных приложений я мало что могу подсказать ибо занимаюсь разработкой игр, но наверное подойдет классический ООП с каким-нибудь сервис локатором

Спасибо большое!

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

Я с ui toolkit знаком только номинально, но по тому что я видел, мне кажется вполне себе применим. По коду разницы нет особо - перерисовывать монобеховский канвас или монобеховский тулкит

Спасибо! У меня есть рубрика паттерны на практике, где я делаю небольшие но полноценные игры Подробного разбора именно архитектуры там нет, но можете посмотреть на гитхабе проекты, две игры уже сделано

Большое спасибо за такие добрые слова! По мере и сил буду дальше стараться рассказывать про разное. Про WPF и Winforms - к сожалению мне будет трудно рассказывать ибо этим я никогда не занимался Про mvvmp - конкретно не слышал, но слышал про различные модификации mvvm. Наверное mvvmp - это очередная прокачанная версия)

Спасибо Про MonoBehaviour - я пользуюсь простым правилом - если тебе монобех не нужен - не используй его :) То есть если у вас есть класс которому не нужны ссылки на префабы, не нужен Awake,Start,OnEnable или корутины - и он не должен как объект висеть на сцене - тогда скрипту MonoBehaviour и не нужен.

Ну конкретно в этом случае да, _itemImage можно сделать private так как в наследнике мы его не трогаем

Можно

@@sergeykazantsev1655 Спасибо

А по вашему, есть существенное различие между использованием одного и того же паттерна в геймдеве или в проектировании БД? Или вы имеете ввиду что вам нужны паттерны, заточенные именно под БД?

@@sergeykazantsev1655 я думаю, что спагетти-код, который очень удобен программисту, когда он разрабатывает приложение, очень неудобен компании, которая уволив этого программиста, возьмет другого, и увидев этот спагетти код тот через месяц скажет, что это никчемное ПО и надо переписывать. Но: паттерны были созданы не для удобства разработчиков, давайте не будем лукавить, паттерны были созданы для удобства компаний, нанимающих разработчиков. Культура использования паттернов крайне противоречива, и "неписаных правил талмут", следование которой сродни путешествию по минному полю. Но никто не хочет признать за разработчиками роли исследователей(творцов) потому что им тогда нужно дать больше прав. Последние годы массовый ажиотаж на ИТ специалистов, но знание ли паттернов определяет успешного разработчика. Я извините, за последний месяц изучил три фреймворка и какие там паттерны(особеннов JS)?

@@sergeykazantsev1655 думаю, что разработчику удобнее сделать спагетти-код, который он оставит в наследие компании, где он работал, а пришедший вновь разработчик через пару месяцев работы с этим легаси заявит о том, что здесь все требует переделки. Паттерны - это некая культура взаимодействия в среде, которая хочет стать обыденной, но никак не может ей стать. И эта мода на программирование - когда кодить пытаются научить каждого таракана, так как для компаний разработчиков рабочий ресурс стал непомерно дорог. Я думаю, что паттерны это просто некий сигнал между специалистами, что они говорят на одном языке, однако нигде нет системного обучения этим паттернам. Или ты попадаешь в проект где с нуля нужно быстро что-то лепить или идешь в большой готовый проект и строишь его помаленьку

Ну чтож, на это я могу высказать только свое мнение - а уж вам решать - соглашаться или нет :) 1. 95% задач с которыми сталкиваются разработчики - не уникальны. Паттерны проектирования - это шаблоны решения этих задач. Паттерны проектирования позволяют каждый раз не изобретать велосипед, тем более что высока вероятность что если вы изобретете это сами -вы что-то забудете, недоучтете и придется модифицировать ваше решение несколько раз 2. С моей точки зрения успешного разработчика характеризуют такие черты как: скорость разработки, качество кода и количество проблем которые он может решить. Условно джун пишет медленно, качество кода так себе, и если бага нестандартная - он не знает как ее пофиксить. Сильный разраб пишет быстрее джуна, пишет качественнее и может решить даже неочевидную и глубокую проблему, написав модификацию какого-нибудь драйвера или плагин. Знание паттернов - улучшает качество и скорость разработки кода. 3. Я не понимаю почему вы противопоставляете интересы компаний и разработчиков. У компаний есть цель - разрабатывать продукт как можно быстрее и как можно качественнее. Разработчики подстраиваются под это и ищут решения как это сделать. Мне как разработчику тоже не нравится читать чужой спагетти код и в нем разбираться). Если же вы хотите быть исследователем и иметь полную свободу - пожалуйста - пилите собственные пет проекты, решения и код - экспериментируйте вдоволь.

Есть паттерн state на канале, это оно)