Swift中面向协议的构建器模式

我是用于创建和验证模型的Builder设计模式的狂热用户。 为什么？ 它使模型创建变得非常简单。

 让用户：用户？  = UserBuilder（） 
  .set（field：.firstName（“ Matt”）） 
  .set（field：.lastName（“ Hoffman”）） 
  .set（字段：.username（“ mhoffman”）） 
  。建立（） 

创建模型时，我通常不知道所传递的值是否有效。 因此，我不能简单地创建模型。 在创建模型以验证字段之前，我必须编写很多逻辑。 如果习惯于在模型外部（即在控制器中）编写此验证，则将发现您重复了代码，并且出于速度考虑，可能会错过错误情况。 模型不是只在一个地方创建的。 它们是从网络请求中读取JSON时创建的，在各种视图中，当您根据用户输入创建模型以在应用程序的其他部分中使用时，这会留出很大的出错空间。

构建器模式解决了重复代码的问题，但是仍然需要您仔细考虑在build()阶段进行的所有验证。 为每个字段编写每个set()函数非常繁琐。 如果我告诉您有人花了几天时间使Builder模式更易于实现，并且更容易包含模型所需的所有验证逻辑，该怎么办？ 这是您的幸运日！

老路

假设您有一个UserSignUp对象，该对象具有字段firstName ， lastName ， username ， password ， confirmPassword ，其中lastName不是必需的。 这就是我以前编写“构建器模式”的方式：

上面的方法是干净且可行的。 如果您不熟悉Builder模式，请继续使用它！ 接下来我将要描述的面向协议的方式实际上需要更多代码，但最终会使验证逻辑更加清晰，当添加新字段时，编译器将警告您尚未通过验证功能处理的验证案例。枚举。

新方法

而已！ 如您所见，在面向协议的构建器模式中肯定有更多的代码，而不是简单地创建一个自定义的构建器，而没有为每个模型重用代码。 但是，每当您将字段添加到面向协议的模式时，如果您不指定字段的验证和isRequired，编译器都会抱怨。 此外，通过这种方法，可以很清楚地在何处添加模型的验证逻辑。 最后，代码重用是很好的，并且如果需要添加其他方法进行验证，那么它可以为所有构建者使用！

该你了

现在，如果您喜欢我在Swift中使用Builder模式的方法，那么恳请您在项目中使用它并获得回报。 然后，当您遇到改进时，请告诉我！

否则，如果您认为我的工作过于复杂，并且您有另一种方法，或者您只是比我更了解Swift并且可以改进此代码，那么我希望收到反馈。

TL; DR

使用构建器模式使模型在Swift中变得强大。 我做了一个面向协议的实现，您可以在这里找到。