在通用应用程序上分离 iPhone 和 iPad 类有什么优势吗？答案

【问题标题】：Is there any advantage on separating iPhone and iPad classes on a Universal app?在通用应用程序上分离 iPhone 和 iPad 类有什么优势吗？
【发布时间】：2012-04-30 13:07:11
【问题描述】：

我有一个通用（适用于 iPhone 和 iPad）应用程序。

在文件夹结构中将 iPad 与 iPhone 类分开有什么好处吗？

这是我的意思的一个例子：

- MyApp
    - Resources
    - Classes
        - iPad
            - SomeUniqueClassOnIPad.h
            - SomeUniqueClassOnIPad.m
        - iPhone
            - SomeUniqueClassOnIPhone.h
            - SomeUniqueClassOnIPhone.m
    - SomeUniversalClass.h
    - SomeUniversalClass.m

这在 Objective-C 项目中很常见吗？

【问题讨论】：

如果您的课程与视图无关（可能会更改），但实现了一些逻辑，那么我认为没有必要将课程分开。这是一个可能有帮助的链接：stackoverflow.com/questions/7315551/…
那个链接让我更加怀疑：stackoverflow.com/a/7315777/807239。由于 iPad 应用程序比 iPhone 应用程序更常用，我应该重新考虑 UI 背后的所有过程以及控制器如何管理它们......这对吗？
基本上，从设备到设备 UI 的变化远远超过逻辑。如果您的应用程序不是“重”，那么我不会重新设计整个处理过程。我在为 ios 开发（更多使用 android）方面的经验很少，但我很少看到该逻辑是为不同的设备单独实现的。安卓也是一样））

标签： objective-c ios xcode coding-style dry

【解决方案1】：

编码中的一条规则是永远不要有重复的代码，所以如果你的视图做不同的事情，或者数据是否应该根据它是 iPad 还是 iPhone 进行不同的处理（例如不同的数据源？）它肯定应该是在不同的班级，如果不是......那么没有。使用同一个类。

在这种情况下你可以实现的一个常见的东西是一种帮助器，如果你愿意的话，它是一个委托类，它处理发生在你的代码中的所有常见方法和操作。

黄金法则：尽可能少写代码！更少的代码 == 更易于维护并且质量更高。因此，在不影响您的要求的情况下编写尽可能少的代码。此外，拆分代码使其更容易（单元）测试，从而更容易重用。

我希望这回答了你的问题。

更新
我知道有一个术语，只是可以想到它。重复代码被称为“DRY-violation”。 DRY 代表 Don't Repeat Yourself，这是软件开发的一项原则，旨在减少各种信息的重复，在多层架构中尤其有用。
更多信息：DRY on Wikipedia

【讨论】：

【解决方案2】：

对我来说，这取决于 iPhone 和 iPad 视图之间的共性。如果有单独的 xib 文件但它们都包含相同的元素，则很容易决定使用相同的类。

如果 iPhone 和 iPad 的 xib 文件具有独特的元素，那么分离类可能会更好。

另一种选择是创建一个由 iPhone 和 iPad 类共享的基类，用于您确实希望将它们分开的情况。基类将包含它们之间通用的代码，例如，启动数据请求或通用自定义视图。

【讨论】：