Video

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

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

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

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

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

Можно

@@sergeykazantsev1655 Спасибо

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

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

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

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

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

В сообществе есть пост, он пока что предпоследний, начинается с "В одной из серий фэнтези книг" - в нем ссылка на все полезные с моей точки зрения ресурсы, там в основном книге, так как видео я мало смотрю - но вот ребята накидали в комментариях неплохо

Добавлю, что вариант "передавать объект класса в метод" не реализуется, т.к. в таком случае отпадает реализация через делегат - (наследник класса ≠ объект класса)

Без кода непонятно ничего, напишите в личку, авось к пятнице прочухаюсь и поищу решение

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

Ну по мне тейк про сокрытие данных не противоречит, а дополняет общую идею инкапсуляции, потому многие их и объединяют. Методы и данные мы помещаем в один объект. Зачем? Мое мнение - затем, чтобы код превращался в маленькие черные ящички, в которых считается логика и чтобы код было удобно сегрегировать по модулям. С функциональными языками такое сделать можно но не так удобно. Модификаторы доступа делаются ровно для того-же, изоляция кода по черным ящикам и чтобы снаружи этот черный ящик никто особо не шатал. Уменьшает количество контроля снаружи. Если выпендриться - можно и не использовать инкапсуляцию - просто делать классы с одними методами без хранения состояния. Но тут по мне как в анекдоте про двух ковбоев в пустыне)

Цитата от Рихтера(CLR via C#) Инкапсуляция данных означает, что поля типа ни в коем случае не следует открывать для общего доступа, так как в этом случае слишком просто написать код, способный испортить сведения о состоянии объекта путем ненадлежащего применения полей. Цитата от Шилдта(Java руководство чего-то там) Инкапсуляция - это механизм, который связывает код вместе с обрабатываемыми данными и сохраняет их в безопасности как от внешнего влияния так и от ошибочного пользования Не могу я вышеназванных дядь назвать какими-то мутными личностями которые ввели дурацкую традицию и ввели всех в заблуждение. Ну разве что если с вашей стороны есть более авторитетные личности которые доказывают что эти авторы заблуждаются и неправы)

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

Как по мне к людям которые больше 20ти лет пишут код, и по своему опыту написали книги и постоянно продолжают их издавать в новых редакциях, к книгам которых с большим уважением и респектом относятся лиды и архитекторы с зп 300к в наносекунду - к этим людям по крайней мере стоит прислушаться. Авось за такое время они что-то поняли. И это я уже не говорю про свой личный опыт, который уже за 7 лет перевалил. Ну а так мы на второй круг заходим - я считаю что сокрытие это не пятое колесо - а полное продолжение идеи изоляции кода от случайного воздействия со стороны. Насчёт того что инкапсуляция происходит и без сокрытия данных - я не понимаю суть этого утверждения. Это как утверждать что "Раз на велосипеде можно ездить без седушки(и я уверен такие бывают) давайте доказывать всем что велосипед это транспортное средство с рулем двумя колёсами но без седла - ибо седушка не обязательна"

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

Так же долго думал как реализовать в одном из своих проектов поиск кратчайшего пути и додумался до волнового способа, который позже нашел в интернете

В том числе именно за это нам и платят, чтобы мы придумывали решения, даже если их нет в интернете)

Как 5к подписчиков наберу, наверное заведу. Пока есть только прямой перевод на карту)

Бороды нет :D

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

Тоже именно R3 сейчас охотно использую)