使用界面构建器是一种不好的实践吗？

Question

我在一家新公司开始了iOS开发工作。他们告诉我永远不要使用Interface Builder，因为它难以维护代码并且有一些限制。

在NetBeans中为Java应用程序使用Interface Builder时，我看到很多“糟糕的代码”，但是我没有使用IB看到过这样的情况。此外，我在互联网上看到了很多IB代码，只有很少的代码没有使用它。

所以对于一个没有人是iOS开发初学者的大型项目来说，使用IB是一种不好的做法吗？

- Guilherme Torres Castro

Answer 1

（首先声明，我强烈反对使用Interface Builder，原因有很多，我将在下文中解释）

他们教我永远不要使用Interface Builder，说它难以维护代码并且有一些限制。

这只是部分正确的。我不喜欢Interface Builder和Xcode的主要原因是，许多初学者程序员认为这是开发iOS/OS X应用程序的唯一方法。他们从未听说过gcc和clang，不知道编译器和链接器错误消息的含义，无法使用make，也不知道Objective-C语言、Cocoa（Touch）API、IDE和编译器之间的区别。

最终，他们开始使用Interface Builder和Xcode，了解其中所有古怪的、有时奇怪/不合逻辑的功能（以及错误），但当他们需要开发一些非常规的东西时，他们甚至没有意识到有一种方法可以通过编程方式创建视图和视图控制器（是的，我在StackOverflow上看到过这个问题）。

因此，当被滥用（或者说是过早使用）时，Interface Builder和所有“方便”的功能会导致程序员学习不良概念并错过一些重要的实践和经验。

然而，如果你是一位资深开发人员，拥有所有必要的技能，并且你觉得自己可以仅使用简单的文本编辑器和Makefile从头编写整个应用程序，那么你完全可以使用IB，甚至鼓励你这样做，如果你觉得这比敲代码更舒适的话。

因此，总结一下：

使用界面构建器真的是一个不好的实践吗？

不是。滥用它并且不努力学习UI编程方法才是不好的实践。

附言：我在iOS开发方面有相当多的经验，但我仍然觉得Interface Builder非常不方便和不一致。我通常对所有东西都使用代码。但这似乎是我的个人喜好。然而，其中一个优点是，如果一个人通过代码创建所有内容，那么另一个没有访问这些苹果特定工具的程序员也将能够为项目做出贡献。这是“难以维护”的部分成立的一个点...

例如，直到我没有足够的钱买Mac之前，我使用Linux开发iOS应用程序(是的，这确实是可能的)。我无法使用IB和Xcode，但我已经完成了大量的应用程序和调整（当然是针对越狱的iOS），而且效果非常好。

附言＃2：避免使用IB的另一个原因可能是需要动态UI。如果您在动画，自定义UI元素等方面严重依赖，则很难在Interface Builder中完成所有工作。去年夏天，我不得不重写一个应用程序的登录屏幕，老实说，如果我必须使用Interface Builder，我不知道如何实现我们设计师的想法。 UI / UX非常动态，并且可以进行许多更改，因此有必要对每个像素进行精细控制。而编码比IB更擅长于做这件事。

- user529758

---

我不同意“你必须对每件事都了解”的说法，但我同意你必须知道何时使用IB，何时不使用(并且能够这样做)。使用IB和动态UI可以做一些非常强大的事情(比如我提到的带有动画刷子等元素的iPhoto UI)，但显然你需要结合实际代码来完成。我绝对不认为IB是不好的做法 :-) - Fogmeister

我认为基于代码的视图更加流畅、模块化和“领域驱动”。基于接口生成器（IB）的视图往往会通过提供臃肿的控制器来破坏MVC，而控制器应该是一个丰富的模型和丰富的视图之间的薄胶水。相反，我们有了一个贫瘠的视图和一个臃肿的控制器。使用基于代码的视图，我们可以拥有一个丰富、可重用的接口。 - Jasper Blues

@JasperBlues 没错。最近我遇到了一位iOS开发者朋友，我们正在讨论控制器过于臃肿的问题。 - user529758

@H2CO3 所以我们可以通过在Xibs中使用多个视图的组合来“修复”这个问题。然而，IB仅为子类提供视觉反馈，而不是由其他视图组成的自定义类。这导致了组合与继承的问题。如果您可以为自定义类分配设计资产图像以获得一些视觉反馈，否则它只是蓝色框，那将很好。所以有一个选择-放弃良好的设计和重用以进行一些拖放，还是不？我想有办法解决这些缺点，但对于复杂的应用程序，我宁愿不去解决它。适用于快速原型制作。 - Jasper Blues

@JasperBlues 是的，没错。IB 适合快速原型设计。但是如果要做更严肃的事情，就不太行了。（这是去年夏天的经验。花哨的动画等在 XIB 中表现不佳。） - user529758

Answer 2

我强烈反对IB是一种不好的实践的想法。与代码相比，Interface Builder具有以下优点：

• 在处理复杂（甚至简单）的图形界面时，IB可以将代码减少到极小的程度——例如，在IB中创建一个按钮只需要几秒钟，而在代码中，这意味着数十行代码，尤其是如果要为按钮添加样式。

• 使用自动调整大小掩码来支持多个分辨率和设备非常容易——这很重要，因为Apple现在正在推动分辨率无关的应用程序。

• 更改/微调视图属性只需要点击几下，而不是写几行代码，特别是当涉及到图片时。

然而，我能想到的一个缺点是：

• 很难确定可能导致图形问题的原因，因为它将被隐藏在IB文件中而不是代码中。

- bibo bode

---

1. 使用类别进行样式设置，您只需要在一个地方担心按钮的样式。
2. 这些点击通常只需要转换为几行代码。点击和滚动比编写涉及自动完成的几行代码要花费更长时间。此外，碎片化较少，查找正确的文件和在IB中检查标记可能需要很长时间。

- Awesome-o

1. 一个按钮不是“复杂的图形界面”，它只是一个简单的用户界面元素。当通过接口构建器创建和修改UIButton，并在以后动态地进行修改时，会发生奇怪的事情，特别是在使用.xib文件时，尤其是如果有许多动态按钮。
2. 这是真的，但如果您的UI元素再次被动画化，我希望您能理解这种痛苦（我没有真正的经验）。
3. 这绝对是正确的，但有一个巨大的问题和WTF。许多属性默认设置不正确，导致奇怪的错误，有时UI元素不响应更改...

- MB_iOSDeveloper

Answer 3

绝对不是这样的。Interface Builder 是一种非常强大的快速创建 UI 的方式，尤其是在使用 Storyboards 时，它允许你仅用很少的代码创建出功能齐全的应用程序。

所谓“它会生成糟糕的代码”这个问题是不正确的，因为 IB 并没有生成任何代码。它生成的文件本质上是 XML 文件，可以与你编写的代码相配合。

我开发过的大多数应用程序都是从 IB 开始的。

显然，你不能完成应用程序的功能部分。例如，你不能告诉一个按钮具体要做什么。但你可以将其指向一个已经编写好的函数，并且几乎不需要编写代码就能获得一个可工作的按钮。

iPad 和 iPhone 上 iPhoto 的大部分用户界面都是使用 Interface Builder 编写的。

- Fogmeister

---

我非常认为xib文件是代码。它们包含指令并最终转换为“二进制命令”，用于CPU - 它们被解释就像Java字节码一样。 - Daij-Djan

我想你是对的。我见过许多所谓的所见即所得编辑器，它们可以创建实际的代码，然后您可以在实际的实现文件中进行编辑（我知道您可以编辑XIB文件）。这就是我理解的“糟糕的代码”。 - Fogmeister

Answer 4

虽然已经有很多讨论，但我仍然想发表我的见解...

在某种程度上，我同意H2CO3的看法，了解底层原理比一味地使用快捷方式更好。这通常是有效的，但是我坚决不同意H2CO3的另一个观点：

• 大多数人使用某种技术（如C＃，Java，HTML，iOS等），是因为他们的公司需要他们使用它，因为其他人实际上会支付您来使用该技术进行工作。而不是因为你真的在半夜醒来，突然想学习C。

• 如果明天有人要求您创建一个iOS应用程序，而您以前从未开发过iOS应用程序，我真的怀疑您是否能够从零开始创建应用程序，而不使用XIB或Storyboard（我讨厌Storyboard）。

H2CO3 提出的是一种乌托邦......在那里，你真正理解了底层的东西，但因为你是这样一个“leet”，你能够使用快捷方式，比如 XIBs。然而，事情并不是这样运作的，迟早你将不得不做一些糟糕的事情，在第二天早上交付某些东西。

我更喜欢，这只是个人观点，使用 XIB，而不是使用出现在我面前的第一个第三方库。我认为这比手工制作界面更为合理。我更喜欢理解代码，并自己做，而不是使用库帮我下载/上传东西。

总之，我对询问此事的人的建议是：

试着理解为什么要这样做。最重要的是，在每个新项目中尝试成为更好的程序员。如果有新的东西出现（新的iOS版本），花一两天去看看有什么新的，以及你可以使用什么。 XIB 用起来很好，但是花些时间手动创建 UIView's，这样你就可以看到它们给你带来的所有灵活性。首先要远离 Storyboards（^^）

顺便说一句：一位资深开发人员不仅仅是一个比你“功夫更好”的人..它远不止于此。

- Rui Peres