Могу добавить ещё один, навеянный статьей, паттерн lele (let to let). let a =0; to let b = a; Очень полезно, не один проект без этого не обходится. Прошу прощения за не форматированный код, пишу двумя мизинцами, руки жирные.
А зачем он нужен? Зачем команда unity тратит силы и средства на то, что лучше получится сделать в сторонних программах, том же бесплатном blender? Лучше бы подумали о зрении студентов и сделали бесплатным темный скин. И ведь наверняка собирают деньги на развитие и тратят их на ерунду, которая никому не нужна.
Я, признаюсь честно, не очень понимаю во всех этих токенах и сборах, но каждый раз когда я вижу что-то подобное в Российском сегменте, это означает что провал гарантирован. Мне кажется что в России не будут давать деньги на универсальные крышки для банок или наушники которые засовываются в ухо на полметра.
Да и нормальные люди знают что 99,9% всех этих сборов улетают «в никуда», а те что выстреливают изначально приходят просить деньги уже будучи раскрученным брендом.
Жаль что у нас так…
Уникальная электроника которая влучшемслучаи из китайских запчастей или в худшем из отечественных (худших по качеству и дороже) в основе которой лежит лучшая российская система на базе linux…
Мы когда-нибудь перестанем тащится в попе и перейдем на шаг вперед… Лучше и брать китайское творение…
да заминусуйте до предела, но я все равно будунастаивать что в 2018 году это полное говно!
И это я ещё не смотрел сами компоненты, они наверняка повторяют компоненты прошлых столетий, то есть нет toolbar, sidebar, stepper и прочие. Да и говорю я это не для того чтобы навредить Вам, а для того чтобы Вы не тратили силы на херню + ещё несколько хренотем! Сделайте сразу то, что увидев мой дизайнер захочет с этим работать, а не то от чего его будет тошнить, так как опыт подсказывает что легче переделать ЭТО будет не так просто.
Я давно не пользовался windows, но я не помню чтобы там были такие уродливые квадраты с жуткой черной огромной обводкой. Скролы просто вообще треш. Если это и использовать, то только все делать самому с нуля. Неужели Вы и впрямь считаете что на сегодняшний день это лучший дизайн по умолчанию?
говорится что «запросить изменения в этом модуле может только Аналитик». Но если никто не может попросить актора что-то сделать, то как тогда он понимает что нужно что-то вызвать?
Например, есть модуль, реализующий некую бизнес-логику, запросить изменения в этом модуле может только Аналитик, но никак не DBA или UX.
Тогда, если двум объектам понадобится изменить один объект, то они попросят сделать это Аналитика.
А разве это не нарушит принцип, так как аналитика будут дергать сразу двое?
И вроде уже давно разобрались что именно эта формулировка как раз и не верная…
Ещё стоит добавить что бояться this не стоит, пока обращения происходят к свойствам объекта получаемого по ссылке this (this.object.prop). Обращение с одной точкой, в большинстве случаев, свидетельствуют о плохо продуманной архитектуре. Но из этого не следует что все части приложения нуждаются в столь продуманной архитектуре, которая будет лишь усложнять процесс разработки не давая никаких плюсов.
Поэтому единственное что можно реально посоветовать — не заморачиваться и делать выбор в зависимости от сложности приложения. Потому что реальный опыт подсказывает, что тот опыт, который был получен при разработке архитектуры слоя приложений не годится для разработки архитектуры компонентов приложения.
Я покажу как находить эти проблемы и решать их с помощью инструментов из функционального программирования.
Их никак нельзя решить. Решить проблемы с this значит полностью отказаться от классов и начать писать на fp. Но тогда появятся другие проблемы связанные с уродливыми параметрами функций и садомазохисткой вложенностью.
Тогда стоит добавить что авторов плагинов для плохо продуманных библиотек.
Зачем делать объекты динамическими, когда можно создать основу конфигурации в виде класса, наделив его базовым состояние, а авторам плагинов позволить его расширять?
Да и нормальные люди знают что 99,9% всех этих сборов улетают «в никуда», а те что выстреливают изначально приходят просить деньги уже будучи раскрученным брендом.
Жаль что у нас так…
Уникальная электроника которая влучшемслучаи из китайских запчастей или в худшем из отечественных (худших по качеству и дороже) в основе которой лежит лучшая российская система на базе linux…
Мы когда-нибудь перестанем тащится в попе и перейдем на шаг вперед… Лучше и брать китайское творение…
Простите не могу льстить безповода…
И это я ещё не смотрел сами компоненты, они наверняка повторяют компоненты прошлых столетий, то есть нет toolbar, sidebar, stepper и прочие. Да и говорю я это не для того чтобы навредить Вам, а для того чтобы Вы не тратили силы на херню + ещё несколько хренотем! Сделайте сразу то, что увидев мой дизайнер захочет с этим работать, а не то от чего его будет тошнить, так как опыт подсказывает что легче переделать ЭТО будет не так просто.
То есть два других актора могут попросить одного Аналитика что-то сделать?
Тогда, если двум объектам понадобится изменить один объект, то они попросят сделать это Аналитика.
А разве это не нарушит принцип, так как аналитика будут дергать сразу двое?
И вроде уже давно разобрались что именно эта формулировка как раз и не верная…
Поэтому единственное что можно реально посоветовать — не заморачиваться и делать выбор в зависимости от сложности приложения. Потому что реальный опыт подсказывает, что тот опыт, который был получен при разработке архитектуры слоя приложений не годится для разработки архитектуры компонентов приложения.
Их никак нельзя решить. Решить проблемы с this значит полностью отказаться от классов и начать писать на fp. Но тогда появятся другие проблемы связанные с уродливыми параметрами функций и садомазохисткой вложенностью.
Зачем элементу хранить json? И гдетогда хранить информацию что toggle=«true or false»?
Зачем делать объекты динамическими, когда можно создать основу конфигурации в виде класса, наделив его базовым состояние, а авторам плагинов позволить его расширять?