我正在编写一个基本上使用5个业务实体的应用程序，A，B C，D和E
它们之间没有任何继承。 没有涉及真正的业务逻辑，对象被创建，填充，然后以只读方式访问，无需进一步操作。
我的自然编码风格是面向对象并为每个实体编写类，使用NSArrays作为列表，并合成所提到的属性。
这会使代码可读。
但另一种方法似乎也很明显：只使用NSDictionaries和NSArrays，并使用键/值而不是属性。这似乎更有效，并且以某种方式“更接近”iPhone风格的编程给我......但显然会导致代码不太可读。另一个优点是不需要额外的自定义编码/解码来进行序列化（将状态保持到磁盘，使用JSON，......） 所以在论文中，它代表了后一种方法，另一方面，它仍然感觉有点尴尬不使用自定义对象......
这真的只是问题的问题吗？或者是否有其他赞成/反对其中一种方法的论据？只使用字典更好的内存/性能吗？它是首选的“Apple Coding Style”吗？ （我来自Java / C＃）。
答案 0 :(得分：4)
我认为Java / C＃和Cocoa在这方面没有太大区别。您的问题同样适用于这些平台（同样适用于键值存储和关系存储）。
在面向对象的环境中，您必须在用于存储数据的键值方法的灵活性与结构化和面向对象的样式之间进行权衡。只有当我需要灵活性时，我才会使用键值方法（例如，结构是动态的，可能会由用户更改或在编译时不知道）。否则，采取这种方式可能会让你完全脱离OOP惯例和好处（顺便说一下，这是重要的一点。坚持面向对象的原则的麻烦在特定情况下值得吗？我认为你的问题减少到了这个并回答它，你应该分析你的具体情况）
答案 1 :(得分：2)
这在很大程度上取决于您的对象是否只是数据集合（键/值对）还是实现了它们自己的功能。
如果他们是数据我会说与NSDictionary一起使用，那么代码的代码要少得多，而且你指出你不必为每个类编写序列化例程。
答案 2 :(得分：1)
使用混合方法。存储对象所基于的词典，但将最常用的值公开为在从字典初始化对象时填充的属性，或者让访问者在字典中查找值（效率较低）。
还提供了获取字典的属性。这样，如果您需要将新值快速传播到字典中代码的特定区域（可能是服务器添加的新值），您就具有这种灵活性。然后，如果调用者大量使用某个值，您可以将其迁移为true属性并获取属性的完成和类型检查。