NSDictionaries против пользовательских объектов со свойствами, что вы думаете?

Question

Я пишу приложение, которое в основном использует 5 бизнес-объектов, A, B C, D и E

• A имеет некоторые свойства и содержит список B's
• B имеет некоторые другие свойства и список C и список D
• C имеет некоторые другие свойства и список D и список E
• D имеет только несколько свойств
• E имеет только несколько свойств

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

Моим естественным стилем кодирования было бы использование объектно-ориентированного программирования и запись классов для каждой из этих сущностей, использование NSArrays для списков и синтезирование упомянутых свойств.

Это сделает код читабельным.

Но очевиден и другой подход: использовать только NSDictionaries и NSArrays и работать с ключами / значениями вместо свойств. Это кажется мне более эффективным и как-то «ближе» к программированию в стиле iPhone ... но, очевидно, приводит к менее читаемому коду. Другое преимущество заключается в том, что для сериализации не требуется никакого дополнительного пользовательского кодирования / декодирования (сохранение состояния на диск с использованием JSON, ...) Так что на бумаге это говорит о последнем подходе, с другой стороны, он все еще чувствует себя как-то неловко НЕ использовать пользовательские объекты ...

Это действительно просто вопрос вкуса ? Или есть другие аргументы в пользу / против одного из подходов? Только использование словарей лучше с точки зрения памяти / производительности? Это предпочтительный стиль Apple Coding Style? (Я с Java / C #).

Answer 1

Я не вижу большой разницы между Java / C # и какао в этой области. Ваш вопрос в равной степени применим и к этим платформам (то же самое относится и к хранилищам ключей-значений и реляционным хранилищам).

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

Answer 2

Это в значительной степени зависит от того, являются ли ваши объекты просто коллекциями данных (пары ключ / значение) или реализуют свои собственные функции.

Если это данные, я бы сказал, что они идут с NSDictionary, кода гораздо меньше, и, как вы заметили, вам не придется писать процедуры сериализации для каждого класса.

Answer 3

Используйте гибридный подход. Сохраните словари, на которых основаны объекты, но предоставьте наиболее часто используемые значения в качестве свойств, которые либо заполняются при инициализации объекта из словаря, либо заставляют методы доступа искать в словаре значения (менее эффективные).

Также укажите свойство в словаре. Таким образом, если вам нужно быстро распространить новое значение на определенную область кода из словаря (предположительно, новое значение, добавленное сервером), у вас есть такая гибкость. Затем, если вызывающие лица интенсивно используют значение, вы можете перенести его в истинное свойство и получить проверку завершения и типа свойства.