如何防弹Swift代码库Pt。 1-自由使用模型
您的代码库中有几个模型？ 5？ 10点 30吗 你应该有几个？ 简短的答案-应该比30更接近30。模型应该高度针对特定上下文，并且应该自由地创建新模型。
假设您正在构建与Instagram类似的应用。 例如，不要使用在整个代码库中使用的一个Account模型，而要创建上下文相关的Account模型，该模型为特定情况下的需求提供最小的负担。 在Instagram克隆应用中，主图片供稿应使用FeedAccount模型，配置文件标签应使用ProfileAccount模型，故事应使用StoryAccount模型，等等。
让我们看看当您决定在整个代码库中仅使用一种Account模型时会发生什么：
您通过应用程序进行思考并决定，最初，模型应该开始看起来像这样：
Account模型包含5个简单易用的属性。
然后，您继续构建应用程序的主要图像供稿功能。 这些图像及其各自的元数据是从REST API端点中提取的。 您对自己说：“太好了！ 我将添加Decodable协议一致性到Account模型，一切都会好起来！”然后，您查看从API请求返回的JSON的结构，看起来像这样
出于网络效率的考虑，您团队中的后端开发人员希望提供实现所需功能所需的最少数据量。 对于主图像提要，唯一需要的“ Account数据是帐户句柄，帐户ID和用于下载与该帐户关联的配置文件图像的URL。 您对自己说：“开枪！ 在完成更改以处理Account模型的新用例之后，最终看起来像这样：
因为不是每个属性都可以通过JSON初始化，所以您必须将未从API请求显式返回的所有属性设为可选。
然后，您继续为应用程序构建主配置文件屏幕。 再次，您查看从后端团队返回的JSON，它看起来像这样：
再次，您修改Account模型以适合此新用例，并得到以下信息：
事情开始变得肮脏。 在仅两个用例之后，最初的Account模型从5个非可选属性开始，现在具有12个属性-其中9个是可选属性，而1个是大多数时间为空的数组。 这是在两个用例之后。
当您构建整个应用程序时会发生什么？
每当出现Account模型的新用例时，您都必须修改现有模型以适合该用例。 这是很难维护的，并且会导致编译器错误和错误。 此外，当有几个人在使用不同的功能，而所有这些都需要使用Account模型时，会发生什么情况？ 每个人都可以更改帐户模型以适应其特定需求吗？ 最终，开发人员将在不知不觉中彼此压倒，造成混乱和混乱。
您将最终获得一个带有50个属性的Account模型，其中大多数是可选的。 我曾经在这样的代码库中工作过，这完全是无法管理的，而且是绝对的痛苦。
让我们看一下如何通过创建多个特定于上下文的Account模型轻松解决此问题。
主图像供稿的Account模型仅需要3个属性。 因此，制作一个仅具有以下三个属性的FeedAccount模型：
繁荣。 简单。
重复ProfileAccount ：
再次，简单。
这种方法使您可以立即在模型中添加和删除属性，而不必担心它将如何影响代码库的其余部分，而不必添加大量可选属性。 此外，模型的特定命名允许团队中的其他开发人员立即识别应该使用该模型的上下文。
您在维护代码库的模型层时遇到问题吗？
向我们发送电子邮件至hello@designpatterninsights.com。
我们帮助像您这样的雄心勃勃的公司构建和维护强大的Swift代码库，以满足业务目标。
