Моделирование ресурсов
Анализ кода показал неудачный подход к моделированию ресурсов. Используемый термин «модель» объединяет данные и бизнес-правила, что приводит к неоднозначности и потенциальным проблемам при работе с несколькими экземплярами приложения. Необходимо выделить чистую модель, независимую от реализации.
Пример: банковский счёт. Модель описывает правила работы со счётом (снятие средств, лимиты), а реализация – интерфейс (Android-приложение, API). Модель должна быть платформонезависимой и использоваться как на клиенте, так и на сервере. Аналогично, в играх обработка урона и брони – это модель, независимая от клиентского или серверного приложения. В анализируемом коде попытка подобного разделения была предпринята, но модель и данные частично смешаны.
Класс DoTheBass описывает данные с типом и именем, заданными строками – это неэффективно. Конкатенация имён также нецелесообразна. Зависимость ресурсов от внешних служб через пути к иконкам вызывает вопросы: данные служб не должны быть частью модели ресурса.
В коде ResourceData – это тип ресурса, а модель – его состояние. Это можно корректно выразить через классы, чего не было сделано. Использование прототипов обсуждается, но реализация не соответствует этой парадигме: объекты не наследуют тип, а имеют ссылку на базовый объект, что меняет порядок доступа к членам.
ResourceData предназначена для передачи данных по сети, а модель – для работы внутри приложения. Это должны быть отдельные объекты. Использование структур вместо классов также обсуждается: структуры лучше подходят для типов данных, а классы – для объектов с поведением. В данном случае, структуры были бы предпочтительнее.
Работа с JSON и командами
Обработка JSON-данных ресурса осуществляется вручную. Модель пользователя и данные ресурсов смешаны, что затрудняет понимание. Система команд использует паттерн Visitor для обработки команд обновления ресурсов. Однако, моделирование команд как структур, а не классов, неверно: экземпляр команды – уникальная сущность.
Важно корректно создавать экземпляры объектов при парсинге JSON. Идентификатор объекта из JSON не должен совпадать с идентификатором объекта в приложении, что может привести к проблемам при сравнении. Решение – воссоздание объекта по идентификатору из приложения.
Конвертеры и сериализация
Реализация конвертации и хранения типов данных неудачна. Использование вложенных словарей вместо дженериков неэффективно. Интересным моментом является использование конвертеров: они позволяют обрабатывать объекты в удобном для инфраструктуры формате (например, идентификатор), а затем находить соответствующий объект в приложении. Конвертеры помечаются атрибутом, и сериализатор использует их для поиска объектов, а не для их создания. Это обеспечивает гибкость при создании и восстановлении моделей из JSON. Однако, в целом, код требует доработки.
Несмотря на наличие интересных решений (в частности, использование конвертеров), код в целом требует доработки. Ключевой момент с конвертерами может быть использован для улучшения качества кода. В остальном, код содержит много недостатков.