iPhone和iPad开发-良好的设计架构，可实现最大的可重用性

我有三个关于iPhone和iPad开发的问题。我正在为iPhone编写一个应用程序，该应用程序将来也应该可以在iPad上使用。通过使用MVC模式，我知道我将保留我的模型，但是我不清楚是否需要放弃控制器和/或视图。因此，我的问题是：

1） 对于那些为两个平台开发相同应用程序的人来说，最佳实践是什么？为了以最小的努力和正确的设计开发这两个应用程序，哪些部分通常是可重用的，哪些部分通常是废弃的

2） 此外，我还需要在应用程序中提供状态/全局信息。如何处理iPhone/iPad应用程序中的（设计方面的）“状态”信息？我目前拥有在整个应用程序中需要使用的用户信息（用户名和密码），以便发出多个服务器请求（编码在http头中）。为了实现这一点，我将用户模型存储在AppDelegate类中。这在设计方面可以吗，还是应该以不同的方式进行

3） 最后，我将模型分为抽象类（或处理泛型的类）和专门处理不同任务的子类。其思想是尽可能少地编写代码以避免代码重复（例如：发送请求是通用的，解析响应取决于手头的任务）。就性能而言，将代码分成几个类并进行模型继承是否存在问题

提前谢谢

1）设计良好的模型、视图和控制器应主要可在iOS设备上重用。平台之间UI设计的差异程度将在很大程度上决定视图控制器的可重用性。例如，在iPad上运行时，视图控制器可能以拆分视图或popover的形式显示，而不是全屏显示，从工具栏按钮项显示的动作表可能没有取消按钮

2） 不要在应用程序委托中存储状态。相反，将其存储在模型类中。用户名和密码尤其应存储在钥匙链中

---

3） 过于复杂的类层次结构会降低灵活性，使理解事物如何工作变得更加困难，但不要担心与类层次结构复杂性相关的性能。相反，要衡量绩效，并花时间优化以最少的努力获得最大回报的地方。这不太可能是超类方法实现查找。

谢谢您的回复。这回答了我的问题。我只有几点意见：1）iPhone版本和iPad版本之间会有差异。iPad版本很可能比iPhone应用程序有更多的功能。我所做的是将控制器作为简单的粘合类，并在模型中包含整个逻辑。我在控制器中有太多与模型相关的信息，因为我担心我必须为iPad版本重新编写控制器，所以我就这样做了。我希望以后不会后悔……2）谢谢你的提示。我真的忘记了这个密钥链API！3） 我之所以尝试建立一些模型层次结构，是因为我想构建一个简单易懂的应用程序，而且我发现了不同类之间的常见操作。我担心这会带来性能开销，但正如您所说，这可能不会影响性能。找iOS模型和面向对象的好例子并不常见，因为我在网上看到的大多数应用程序都使用控制器来存储模型信息。（不得不将我的评论分成3条…对此表示抱歉）