Войти
Инди-ЮнитиФорум

Мастер класс по хорошему коду в юнити (28 стр)

Страницы: 123 24 25 26 27 28
#405
21:13, 1 фев. 2021

Т.е. ты не знаешь js?
Архитектору непозволительно не знать функциональные языки, а js один из самых распространенных.


#406
21:14, 1 фев. 2021

seaman может он на питоне пилит тулзы :)

#407
(Правка: 3:58) 1:04, 2 фев. 2021

Любой желающий может перечитать тред, и убедиться, что:

> а вот тут, действительно, оказывается разница где-то в 10 раз между сохранением
> текста и бинарным представлением. Это я действительно, не дооценивал.
это было неоднократно сказано и подчёркнуто мной несколько раз, но tac продолжал настаивать, что его текстовый пример всё равно быстрее. Если ты не можешь даже примерно оценить стоимость операции, то что же брался утверждать? Вопрос риторический. А после tac слился и отказался сравнивать результаты теста.

1.1
> Это может применяться в различных подзадачах - как то просто сохранение игры для игрока, различные подсохранения состояний игровых объектов (как то был пример у меня с неким манипулятором, у которого игрок может задать разные программы, и в течении игры их надо запоминать и менять), для диалогов и много где. Основной признак этого - сохранение ряда свойств разных объектов объязательно с выгрузкой на постоянный носитель - в файл или БД (причем БД, тоже может быть файловая). И не будем это путать с клонированием (!).
tac изначально спорил с позицией, что сериализация вообще нужна кому-либо на проекте без клиент-серверной архитектуры. В ранних сообщениях он прямо утверждал, что во всех случаях это можно и нужно заменить на единую реляционную БД, а иначе вы бездари.

> объязательно с выгрузкой на постоянный носитель - в файл или БД
Ложное утверждение. Для того, чтобы реализовать инспектор свойств объекта в течение игры, совершенно избыточно делать это через обращение к постоянному носителю. Только здесь уже речь идёт о потере производительности не в 10 раз, как в случае с текстовым форматом, а в 100 и более. Также существует масса контекстов, где после использования сериализации результат сохранять на постоянный носитель вообще не нужно (даже отложенно). Например, если речь идёт об изменении скорости анимаций и других настроек, привязанных к конкретной сессии; о клонировании объектов в памяти; хранении и выводе на экран сведений о сессии, например, лога ошибок; и многие другие применения.

> причем БД, тоже может быть файловая
taс изначально утверждал, что файловая база данных — это сделанная на коленке nosql-база, но нет ничего лучше, чем реляционная база данных во всех контекстах, за исключением сетевого. Идёт попытка подменить задним числом свои тезисы и присвоить себе аргументы оппонента.

> И не будем это путать с клонированием
Как было показано, в контексте клонирования объектов tac пользуется чужой сериализацией. Причём не ручной, а с применением атрибуции Unity (так работает Instantiate).

1.2
> Сохранять можно в разных форматах, два из которых наиболее важны - текстовый (как наиболее репрезентативный для разработчика), и бинарный (о котором стоит позаботится, если хочется больше скорости). И иметь возможность их преобразовывать один в другой.
Ещё одна попытка присвоить себе тезисы оппонентов. Как видно из примеров tac'а, он всегда реализует только один формат в своих проектах; о преимуществах бинарного узнал лишь в процессе этого треда. Ну а преобразование формата из одного в другой так и подавно не смог показать даже в своих поздних примерах. Несмотря на неоднократные указания на это.

1.3
> В случае баз данных в виде хранилища, тут ничего принципиально не меняется -
> это просто другой физический носитель, и в нем можно так же хранить в разных
> форматах, только добавляется еще вариант с реляционным форматом. Главное
> правильно использовать когда это нужно.
Принципиально меняется то, что становится невозможным контроль версий через VCS и одновременная работа над одними объектами. А это является неотъемлимой частью профессиональной работы в крупных командах последние лет 15.

> Когда нужен одновременный доступ к разным объектам - совершенно не правильно использовать файл
То есть всегда в профессиональных командах. Что и требовалось доказать.

> Вначале можно держать в разных файлах, или в свойствах префабов, часто этого хватает, но лучше внешние данные организовывать в БД, особенно если у вас в игре есть сеть.
Избыточно дополнительно организовывать данные в БД, если они и их история уже хранятся под VCS (см. выше). БД не добавляет никаких преимуществ.

2
> При том, что задача описанная в п.1., естественно полезная и нужная, очень вредно делать это через т.н. сериализацию, и не будем путать её с записью данных в поток (текстовый или бинарный).
Человек фактически утверждает что вещь не равна своему определению:

Сериализация (в программировании) — процесс перевода какой-либо структуры данных в последовательность байтов

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

> Основным признаком современной сериализации, является то,
> что движки заставляют расставлять атрибуты в классах исходного кода,
> что совершенно не приемлемо.
Полная ерунда. Атрибуты — это всего лишь надстройка для управления процессом сериализации. Сама сериализация может происходить, как под управлением атрибуции, так и без. Отличный пример, это Protocol Buffers. В оригинальной библиотеке от Google нет никакой атрибуции. Она появляется только в библиотеке protobuf-net, который является альтернативной реализацией. Если к сериализации относить только то, где можно проставлять атрибуты, то практически все библиотеки сериализации для С++ таковыми не являются.

> что совершенно не приемлемо
Совершенно неприемлемо, это когда производительность падает в 10 раз из-за незнания архитектором основ стоимости операций. Или когда большой распределённой команде советуют использовать БД вместо VCS для контроля версий. А использование атрибутов имеет, как свои плюсы, так и минусы. В индустрии нет единого мнения, что перевешивает, это больше из области вкусов.

2.1
> Чисто стилистически атрибуты "заполняют" и смешиваются к кодом, и в этом случае доводится до абсурда использование атрибутов, в то время как атрибуты, в этом случае используются не по назначению с точки зрения ООП (но многих это почему то мало волнует, к сожалению)
Как я упоминал выше, точка зрения имеет право на существование и с кем-нибудь другим можно было бы подискутировать на тему. А с тем, у кого даже нет поддержки совместимости сохранений, и кто отрицает её необходимость, обсуждать плюсы атрибуции бессмысленно. Он их даже не поймёт, так как никогда не сталкивался с поддержкой собственных форматов.

2.2
> Но главная беда, что такой сериализацией не возможно управлять, она становится
> статической на все время - все или ничего и только один раз.
Вранье или некомпетентность. Неоднократно мною было показано (даже мой видео-доклад на эту тему показал), что моя сериализация позволяет мощнейшим образом управлять процессом. Доступна сериализация в один пакет или распределённо; выборочное исключение объектов, но с сохранением ссылок на них; выборочное исключение отдельных полей в зависимости от режима сериализации; склеивание одного объекта из нескольких источников; выбор текстового или бинарного формата, исключение или замена полей в каком-то из них; автоматическая конвертация старых полей и поддержка будущих версий; задание альтернативных форм записи для конкретных полей; и другое.

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

#408
(Правка: 1:30) 1:29, 2 фев. 2021

tac
Я предупреждал, что будут санкции, если будешь продолжать и дальше тратить моё время (бан).
На этом сайте не нужны мастер-классы от лже-гуру.

Страницы: 123 24 25 26 27 28
Инди-ЮнитиФорум

Тема закрыта.