pList или жестко закодированные объекты?

Question

В моем приложении мне нужен краткий список объектов класса Person .Каждый Person имеет несколько свойств, таких как name , firstName , age и так далее.До сих пор все объекты были жестко запрограммированы в Objective-C и добавлены в NSMutableArray.Этот подход идеально подходит для моих нужд, так как мне не нужно добавлять какие-либо дополнительные объекты во время выполнения.

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

Мне не нужны какие-либо базовые данные (я полагаю), так как все, что мне нужно, этосписок объектов, которые никогда не изменятся и не должны быть изменены пользователем.

Answer 1

Преимущества использования файла plist следующие:

• вы можете иметь много plist в вашем проекте и легко переключаться по коду на список, который вы хотите загрузить.Полезно, например, при тестировании вашего приложения с несколькими пулами данных или, например, иметь один plist для каждой локализации (один для английского, один для испанского, один для китайского и т. Д.)
• Вы можете загрузить/ выгрузить данные, чтобы они не застряли в памяти
• Вы можете сохранить файл plist, изменить его по любой причине и восстановить его, не теряя "настоящий" код приложения, который вы изменили.

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

Answer 2

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

Если вы пытаетесь использовать plist для большей гибкости (возможно, для модульного тестирования), вы можете реализовать NSCoding и архивировать / разархивировать в двоичный plist.

Answer 3

У меня была похожая ситуация, и я, в конце концов, пошел с списком.Он взял много строк повторяющегося кода при запуске моего приложения (что было для меня наибольшим преимуществом) и значительно облегчил добавление или изменение элементов в дальнейшем.Я был бы удивлен, если бы, байт за байтом, потребовалось значительно больше «символов», чтобы сделать это в листинге по сравнению с кодом (очевидно, код меньше при компиляции, но о чем мы говорим, несколько килобайт?).