以正确的方式处理Swift第1部分

扩展，委托，黑盒，覆盖

不要这样

MyViewController类：UIViewController，UITableViewDelegate，UITableViewDataSource，UIPickerViewDelegate，UIPickerViewDataSource {…}

为什么？ 这是不好的编码，您可能会继续向MyViewController添加更多的委托类，并使该类变得可怕。 记住规则：模块必须少于400行代码，包括注释。

像这样

制作一个名为MyViewControllerTableExt的新Swift文件，并将其添加

扩展MyViewController：UITableViewDelegate，UITableViewDataSource {…}

制作另一个名为MyViewControllerPickerExt的新Swift文件，并将其添加

扩展MyViewController：UIPickerViewDelegate，UIPickerViewDataSource {…}

为什么？ 这些文件的名称将使代码更易于阅读和调试。 在小模块中跟踪错误比千行模块容易得多。 这也是良好的编码习惯。 几个月后，回顾一下代码，您会发现它们仍然易于阅读和维护。

不要这样

从父控制器

self.present（childViewController，animation：true）{}

然后从该子控制器中按一个按钮

self.dismiss（动画：true）{}

为什么？ 这是错误的编码。 父母失去了控制。 它打电话给孩子，直到孩子决定解散自己才知道工作何时完成。 在最坏的情况下，父母可能会叫几个孩子，却不知道哪一个仍在记忆中。 这是不对的。 除非子控件是类似于box的单按钮屏幕，否则不要使用它。

像这样

创建一个名为globalStruct的快速文件，并添加此文件

协议ChildDelegate：类{

func childResult（数据：字符串）

}

在子viewController中，添加委托

class ThisChildViewController：UIViewController {

弱var委托：ChildDelegate？

…

}

当孩子完成工作后，将控制权和数据传回给父母，然后它将做

自委托。 childResult（结果）;

请注意， 孩子不会调用self.dismiss。

然后从父目录创建一个名为MyViewControllerChildExt的新Swift文件，并执行以下操作

扩展MyViewController：ThisChildDelegate {

func childResult（data：String）{

self.dismiss（animated：true）{//父级在其控件中关闭子级

process_data（data）;

}}}

为什么？ 这是正确的方法。 这是适当的软件工程。 在本系列的后面部分，我们将进一步进行设计和编码。 目前，想法是父母必须控制住。 它打开并关闭子进程，然后处理子进程中的数据。

注意，该协议被定义为全局结构，所有需要向其父级发出信号的子级都可以使用委托。

默认情况下，黑盒将具有输入并产生输出。 它用作单功能模块，例如电气转换器，输入220V 10A，输出110V 10A。 在实践中，无需知道黑盒内部的内容。 如果有任何问题，我们只需要购买另一个转换器即可。

如果模块像黑盒一样工作，则父级使用输入参数调用它并获取结果输出。 父级是呼叫者，将子级称为被呼叫者，取回数据，然后关闭被呼叫者。 通过使用黑盒方法，可以更轻松地进行模块测试和调试。

例如，一个底盒函数作为加法，它使用两个整数作为输入参数，并返回两个参数的总和。 既然我们知道了预期的参数和预期的结果。 我们可以在单元测试中消除大多数无效的输入和输出。

不要这样

为什么？ 这不是黑匣子。 黑匣子模块始终将数据发送回调用方。 黑盒模块是唯一的模块。 它不调用其他模块。 父母/主叫者愿意。 黑匣子没有。

像这样在iOS中使用黑盒

这是典型的黑匣子。 父级调用此模块，传递一个针脚，此黑盒将匹配该针脚，并向父级返回true或false。 家长将从那里决定锁定设备，提供警告或进入下一个模块。

同样， 黑匣子不会进入下一个级别。 父母做。

如果此黑匣子出现故障或经理决定更换它，该怎么办？

由于黑匣子是可替换的，因此只需插入另一个黑匣子即可。

想法是，如果适当地进行工程设计，则该应用程序将相当灵活，可以通过黑盒模块的插入方法进行扩展 。

不要这样

为什么？ 主模块A完全失去了控制。 被调用模块C之后的模块B也失去控制，依此类推。 这称为意大利面条代码。 即使由执行此操作的同一位编码人员进行调试，意大利面条式代码也是一个噩梦。 为了修复错误而对一个模块进行更改可能会在其他模块中引起新的错误。

意大利面条代码还留下许多打开的模块，从而导致内存问题。 没有垃圾收集可以处理此问题，因为没有迹象表明该类已被取消。 没有经过软件工程方面正式培训的人都可以这样做。 但是，它发生了。

在现实生活中可以看起来像这样

让我们不计算框架，库和假设一个屏幕占用20M。 这个意大利面条模块沿打开三个屏幕的方式离开，从IOS分配给应用程序的60M细小堆中被带走。 正如父母控制的规则还表明，在这种情况下父母/呼叫者完全失去了控制。

像这样

为什么？ 首先，它用于内存管理。 大多数情况下，根目录将在内存中保留一个屏幕。 有时，navigationController下可能有两个相关的屏幕，它们将使用后退按钮自己管理popViewController。 而且，它是用于软件工程的适当结构。 根控制其子模块。 从此视图中，该图是可读的，并且逻辑流程是可见的。

苹果商店拒绝的许多应用程序都存在内存过载的情况，要么由1）错误的编码器完成，要么由2）混合代码生成器完成。 当项目状态不好时，问题往往会在稍后阶段显现，因此很难处理代码生成器。 但是，如果编码错误，它仍然可以治愈：必须重新设计工作。

让我们转到第2部分了解更多信息。