从概念上讲，UIView的子类是否正确？

Question

（我不是说它不是，为了确保我正确地实现面向对象的原则，我更多的是要求。）

我想创建一个UIView，其中UIImageView位于其中，UILabel位于UIImageView字幕下方。{/ p>

在iOS应用中，如果我想在应用的多个部分中使用此设置，那么重用此UIView设置的最佳方法是什么？

我看来很多教程都指向子类UIView，并在其中一个init方法中创建子视图，然后将它们添加到self，瞧，只需创建此UIView子类的新实例，您实现了 reusable 。

但这个“带标题的图像”概念是否有意义成为UIView的子类？我理解子类和继承就像你有一个名为Vehicle的超类，并且你创建了一个名为Truck的子类。如果你看一下，“卡车”是“车辆”，这就是我理解继承的方式。

  

“带标题的图片”是“视图”

在继承中有概念意义吗？我知道很多人会说“当然是！”但我只是看着它，并认为它不是超类的推导或定制，而是其他一些的合并。

如果我正在创建类似的东西，我几乎在想我想要一个可重复使用的UIView 自定义实例，比UIView的子类还要多，但也许我我对子类化的定义过于尖锐。

如果我只想要一堆带有特殊字体的红色UIButtons我可以重复使用该标签怎么办？这真的是用于子类化吗？

子类化是最好的选择吗？或者也许从笔尖创建并使用代码导入它会更好？

Answer 1

对它进行子类化是一个非常好的选择。您需要记住UILabel和UIImageView实际上是UIView的子类。实际上，UIKit中的所有内容都来自UIView。子类化的重点是自定义对象。这绝对是一个很好的方法。

Answer 2

如果只需要重用视图+使用nib / xib文件布局就足够了。 如果你想要一些参数和动作，最好是子类。

Answer 3

  

如果我正在创建类似的东西，我几乎以为我想要一个可重用的UIView自定义实例，比UIView的子类更多，但也许我对子类的定义过于尖锐。

您正在考虑prototyping，这是设计面向对象系统的合理方法。 Self是典型的例子，但JavaScript可能是最着名的。 Objective-C通常不使用原型。 （除非它实际上使用它来观看很多视图，几乎就是你如何描述它......更多的是一秒钟。）

首先考虑聚合方面的类是非常正确的，只是稍后才转向继承。在许多情况下，创建配置库存UIViewController的{​​{1}}子类更自然。但有时那是笨重的。同样，我会在UIKit示例中查看UIView子类中有意义的指导，以及不可行的指导。但是，将UIView的子类子类化是很有意义的。深层对象层次结构在（好）ObjC中并不常见。最好将复杂性转移到控制器和委托中。

但我说UIView使用原型很多。确实如此。它们被称为nib文件。一个nib文件只不过是一堆克隆到你系统中的序列化原型（大多数时候这些是视图，但它们实际上可以是任何东西）。在Interface Builder中配置复杂视图，然后使用UINib自行实例化它们没有任何问题。我自己完成了这项工作，而不是创建复杂的UIView子类。

每隔一段时间，克​​隆一个现有的，预配置的视图原型确实很有意义，而且我已经在几种情况下完成了它（特别是当用户以某种方式配置了视图时）。您可以使用UIView执行此操作（将视图序列化为数据，然后将其反序列化为视图）。但这不是常用方法。

所有这一切，对于您的标题图片视图的特定情况，我几乎肯定会将其构建为NSCoding个人的子类。

Answer 4

对于您的用例，似乎您有一个好主意，似乎是另一种观点的明智选择。 DDDImageCaptionView

确保你有一个良好的model, view and controller分隔，以确保你没有使用视图存储数据，视图应该是愚蠢的，并显示它告诉的内容。