add swift-protocols-app-configuration #282
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Nemocdz
requested changes
Dec 28, 2019
|
第一次修订好啦～谢谢校对同学～@Nemocdz |
Nemocdz
requested changes
Jan 4, 2020
| @@ -51,25 +51,25 @@ protocol SettingsManageable { | |||
| } | |||
| ``` | |||
|
|
|||
| 我之前简单地解释过，我们将会通过对 `SettingsManageable` 协议中定义的方法，进行默认的行为实现，这样我们可以通过采纳协议来得到我们想要的功能性。在明确这一点之后，直接在上面这个协议的花括号后面加上几个空行，然后定义它的扩展： | |||
| 我之前简单地解释过，我们将会通过对 `SettingsManageable` 协议中定义的方法，进行默认的行为实现，这样可以通过遵循协议来得到我们想要的功能性。在明确这一点之后，直接在上面这个协议的花括号后面加上几个空行，然后定义它的扩展： | |||
| 定稿= | ||
|
|
||
| <!--此处开始正文--> | ||
| 大家好欢迎阅读这篇新教程！协议是广大程序员们在使用 Swift 时最常接触并且使用的概念之一，并且我不认为有任何一个程序员不知道协议。协议常常被用于各种目的，但被大家记住的永远都是苹果官方文档中所描述的： |
There was a problem hiding this comment.
并且我不认为有任何一个程序员不知道协议 -> 不会有不知道协议的程序员
|
|
||
| 用更简单的话来说，一个 Swift 协议定义了一些方法和属性，需要由协议采用类型（类，结构体，枚举）来实现。定义的这些方法和属性被称为*约定*。 | ||
|
|
||
| 让协议特别有趣的一点在于，可以简单地通过对协议提供扩展，来提供默认实现的能力。事实上正是这个功能，让协议可以如此强大并且成为 Swift 开发中流行话题的原因。通过定义一组方法来描述一系列功能，并对它们提供基础的实现。甚至可以让与其无关的类，结构体，枚举类型（与之相反的例子是类的继承）也能够获得一个通用的附加功能，这些附加能力扩展了他们的功能性。 |
|
|
||
| 用更简单的话来说，一个 Swift 协议定义了一些方法和属性，需要由协议采用类型（类，结构体，枚举）来实现。定义的这些方法和属性被称为*约定*。 | ||
|
|
||
| 让协议特别有趣的一点在于，可以简单地通过对协议提供扩展，来提供默认实现的能力。事实上正是这个功能，让协议可以如此强大并且成为 Swift 开发中流行话题的原因。通过定义一组方法来描述一系列功能，并对它们提供基础的实现。甚至可以让与其无关的类，结构体，枚举类型（与之相反的例子是类的继承）也能够获得一个通用的附加功能，这些附加能力扩展了他们的功能性。 |
| 好了，那到底协议与这篇文章标题所说的应用设置有什么关系吗？让我来解释一下其中的联系。很久以来，我一直都因 [**UserDefaults**](https://developer.apple.com/documentation/foundation/userdefaults) 是唯一可以快速地存储少量数据的机制而感到苦恼。毋庸置疑 User Defaults 是挺好的，但这是一种笼统地并且不 “Swifty” 的方案（说实话，我已经很少使用它们了）。我需要的是一种能够为我的每个应用量身定做的解决方案。迈向这个目标的第一步很简单：创建一个包含了应用配置和用户偏好的类或者是结构体。然而这个方案的缺点在于所有的这些选项，都需要对应的文件操作方法（保存，加载，删除）。方法应该只编写*一次*，就能够在*任何*地方被*任何类型*使用。通过类和继承来实现这些基础功能的想法可以直接抛弃了，因为这会阻碍我们使用结构体（`struct`）。这就是协议大展身手的时候了！ | ||
|
|
||
| # 线路图 | ||
| 我们今天的目标是创建一个可以被任何类型采用，支持简单地保存以及从文件中加载其数据的协议。将其命名为 **SettingsManageable**，随着我们一步一步地从零开始，最终会让它完全正确地运作。然而要记住，我们的重点是如何轻松地处理应用的设置以及设置相关的通用类型，并不是如何通过不同地方式来保存各种的类或结构体的数据。为了达成这个目的，接下来将要创建的文件是 *属性列表*（.plist）。毕竟当考虑设置的实现时，编辑一个属性列表通常会是第一个出现在脑海中的方案。为了更好玩，我们要加上对应用包中默认初始设置处理的支持（那些可以在 Xcode 属性列表编辑器中编辑的设置）。 |
| # 线路图 | ||
| 我们今天的目标是创建一个可以被任何类型采用，支持简单地保存以及从文件中加载其数据的协议。将其命名为 **SettingsManageable**，随着我们一步一步地从零开始，最终会让它完全正确地运作。然而要记住，我们的重点是如何轻松地处理应用的设置以及设置相关的通用类型，并不是如何通过不同地方式来保存各种的类或结构体的数据。为了达成这个目的，接下来将要创建的文件是 *属性列表*（.plist）。毕竟当考虑设置的实现时，编辑一个属性列表通常会是第一个出现在脑海中的方案。为了更好玩，我们要加上对应用包中默认初始设置处理的支持（那些可以在 Xcode 属性列表编辑器中编辑的设置）。 | ||
|
|
||
| 在完成实现之后，我们还会看到一些如何使用这个协议的简单示例。虽然在这里是处理的属性列表数据，也欢迎你来对其扩展更深一步，让协议更通用，让它可以支持任何自定义类型以及其他的数据类型比如 JSON 或是纯文本。 |
| 如果 `loadUsingSettingsFile()` 方法返回 true，那么执行则会走到里面的 `else`，并且方法会返回 true。另一种情况，如果恢复初始设置成功了，则会返回 `load()` 方法的执行结果。无论初始设置是如何被定义的，是直接设置给属性，还是通过应用包中的属性列表文件，上面的实现都会正常工作。你或许会想为了实现一个重置的功能费这么多功夫是否值得，但相信我，值。随着时间的推移，你绝对会需要这个功能，而那时候就可没有那么多时间来实现了！ | ||
|
|
||
| # 将属性列表内容当作字典 | ||
| 所有 `SettingsManageable` 协议中方法的目的，都是为所有遵循了协议的类或结构体，提供对应的保存和加载的方法。数据保存是通过 `PropertyListEncoder` 编码后存储为属性列表文件，然后通过 `PropertyListDecoder` 来解码。诚然，与属性列表数据和其相关的类打交道的机会，并不像遇到 JOSN，`JSONEncoder` 和 `JSONDecoder` 那么多。所以借此机会，那就让我们来更进一步地使用它，来看看怎么使用 `PropertyListSerialization` 类以及如何将属性列表作为字典类型获取。 |
|
第二次修订好啦～@Nemocdz |
Nemocdz
approved these changes
Jan 8, 2020
WAMaker
requested changes
Jan 22, 2020
| 定稿= | ||
|
|
||
| <!--此处开始正文--> | ||
| 大家好欢迎阅读这篇新教程！协议是广大程序员们在使用 Swift 时最常接触并且使用的概念之一，并且我认为不会有不知道协议的程序员。协议常常被用于各种目的，但被大家记住的永远都是苹果官方文档中所描述的： |
| 定稿= | ||
|
|
||
| <!--此处开始正文--> | ||
| 大家好欢迎阅读这篇新教程！协议是广大程序员们在使用 Swift 时最常接触并且使用的概念之一，并且我认为不会有不知道协议的程序员。协议常常被用于各种目的，但被大家记住的永远都是苹果官方文档中所描述的： |
| 定稿= | ||
|
|
||
| <!--此处开始正文--> | ||
| 大家好欢迎阅读这篇新教程！协议是广大程序员们在使用 Swift 时最常接触并且使用的概念之一，并且我认为不会有不知道协议的程序员。协议常常被用于各种目的，但被大家记住的永远都是苹果官方文档中所描述的： |
There was a problem hiding this comment.
并且我认为不会有不知道协议的程序员。
这里的并且可以去掉，和前面的 并且 连着用读起来有点奇怪
| <!--此处开始正文--> | ||
| 大家好欢迎阅读这篇新教程！协议是广大程序员们在使用 Swift 时最常接触并且使用的概念之一，并且我认为不会有不知道协议的程序员。协议常常被用于各种目的，但被大家记住的永远都是苹果官方文档中所描述的： | ||
|
|
||
| > 协议是定义方法，属性和其他符合某种特殊任务要求的蓝图。协议可以被类，结构体或是枚举采用，根据其定义提供符合要求的实现。任何类型只要满足了协议的要求，就可以被称为是满足了该协议。 |
There was a problem hiding this comment.
任何类型只要满足了协议的要求，就可以被称为是满足了该协议。
=>
任何类型只要满足了协议的要求，就可以被称为是遵循了该协议。
| > 协议是定义方法，属性和其他符合某种特殊任务要求的蓝图。协议可以被类，结构体或是枚举采用，根据其定义提供符合要求的实现。任何类型只要满足了协议的要求，就可以被称为是满足了该协议。 | ||
| <!--more--> | ||
|
|
||
| 用更简单的话来说，一个 Swift 协议定义了一些方法和属性，需要由协议采用类型（类，结构体，枚举）来实现。定义的这些方法和属性被称为*约定*。 |
| 如果你是一个新手开发者，那么我强烈推荐你阅读 [**更多关于协议的信息**](https://docs.swift.org/swift-book/LanguageGuide/Protocols.html)，你可以在那里发现有许多有趣的信息。 | ||
|
|
||
| 好了，那到底协议与这篇文章标题所说的应用设置有什么关系吗？让我来解释一下其中的联系。很久以来，我一直都因 [**UserDefaults**](https://developer.apple.com/documentation/foundation/userdefaults) 是唯一可以快速地存储少量数据的机制而感到苦恼。毋庸置疑 User Defaults 是挺好的，但这是一种笼统地并且不 “Swifty” 的方案（说实话，我已经很少使用它们了）。我需要的是一种能够为我的每个应用量身定做的解决方案。迈向这个目标的第一步很简单：创建一个包含了应用配置和用户偏好的类或者是结构体。然而这个方案的缺点在于所有的这些选项，都需要对应的文件操作方法（保存，加载，删除）。方法应该只编写*一次*，就能够在*任何*地方被*任何类型*使用。通过类和继承来实现这些基础功能的想法可以直接抛弃了，因为这会阻碍我们使用结构体（`struct`）。这就是协议大展身手的时候了！ | ||
|
|
There was a problem hiding this comment.
这两段应该是翻译后新加的...🤦♂️
是我校对晚了=。=
|
修订好啦～谢谢 @WAMaker |
WAMaker
requested changes
Feb 4, 2020
| > 协议是定义方法，属性和其他符合某种特殊任务要求的蓝图。协议可以被类，结构体或是枚举采用，根据其定义提供符合要求的实现。任何类型只要满足了协议的要求，就可以被称为是遵循了该协议。 | ||
| <!--more--> | ||
|
|
||
| 用更简单的话来说，一个 Swift 协议定义了一些方法和属性，需要由协议遵循类型（类，结构体，枚举）来实现。定义的这些方法和属性被称为*约定*。 |
|
|
||
| 好了，那到底协议与这篇文章标题所说的应用设置有什么关系吗？让我来解释一下其中的联系。很久以来，我一直都因 [**UserDefaults**](https://developer.apple.com/documentation/foundation/userdefaults) 是唯一可以快速地存储少量数据的机制而感到苦恼。毋庸置疑 User Defaults 是挺好的，但这是一种笼统地并且不 “Swifty” 的方案（说实话，我已经很少使用它们了）。我需要的是一种能够为我的每个应用量身定做的解决方案。迈向这个目标的第一步很简单：创建一个包含了应用配置和用户偏好的类或者是结构体。然而这个方案的缺点在于所有的这些选项，都需要对应的文件操作方法（保存，加载，删除）。方法应该只编写*一次*，就能够在*任何*地方被*任何类型*使用。通过类和继承来实现这些基础功能的想法可以直接抛弃了，因为这会阻碍我们使用结构体（`struct`）。这就是协议大展身手的时候了！ | ||
|
|
||
| 通过协议定义一系列负责文件处理的方法，以及通过协议扩展提供这些方法的默认实现。这样一来每一个遵循了协议的类或结构体，都能够获得相同的文件相关的功能。不仅如此，支持了各种设置的类或结构体还能以这种方式同时存在于应用中，这些数据也能被分别处理。换句话说，这种协议就像是某种即插即用机制，可以使任何遵循它的自定义类型具备保存和读取数据的能力。 |
There was a problem hiding this comment.
都能够获得相同的文件相关的功能。
原文句末用的是 感叹号
| 这是我长期以来都在使用的解决方案，现在是时候将它拿出来在这讨论了。这篇文章所讨论的内容很显然是针对 Swift 开发新人的，可以让他们了解协议，以及协议的实际用法。毫无疑问高级开发者们早已有了类似的解决方法，但无论你处于什么阶段，都推荐继续阅读下去。 | ||
|
|
||
| # 线路图 | ||
| 我们今天的目标是创建一个可以被任何类型遵循，支持简单的保存以及从文件中加载其数据的协议。将其命名为 **SettingsManageable**。我们将一步一步地从零开始，直到最后让它完全正确地运作。但是要记住，我们的重点是如何轻松地处理应用的设置以及设置相关的通用类型，并不是实现如何通过不同地方式来保存各种的类或结构体的数据。所以为了达成这个目的，接下来将要创建的文件是 *属性列表*（.plist）。毕竟当考虑到设置的实现时，编辑一个属性列表通常会是首先出现在脑海中的方案。为了更好玩一些，我们要加上对应用包中默认初始设置文件的处理（那些可以在 Xcode 属性列表编辑器中编辑的设置）。 |
There was a problem hiding this comment.
我们今天的目标是创建一个可以被任何类型遵循，支持简单的保存以及从文件中加载其数据的协议。
=>
今天的目标是创建一个协议，让遵循它的类型能以文件的形式很方便的读取或写入。
| 这样可以避免有的类型没有遵循 `Codable`，但遵循了 `SettingsManageable`，导致我们接下来无法为其提供正确的功能。 | ||
|
|
||
| # 定义并且实现协议的要求 | ||
| 这是这篇文章最有趣的部分了，当我们实现了所有的方法之后，就能够让任何遵循了 `SettingsManageable` 的类或结构体能够自动地保存及加载自身。因此我们作为开发者，可以在没有任何代价的情况下，将它们当作是设置或偏好选项来对其改动或是更新。从现在起，我们将会定义协议中的每一个方法，并且我们会在协议扩展中提供对应的实现。话不多说，让我们开始吧！ |
There was a problem hiding this comment.
就能够让任何遵循了 SettingsManageable 的类或结构体能够自动地保存及加载自身。
去掉第二个 能够
| } | ||
| ``` | ||
|
|
||
| 第一行从缓存目录获取到了 URL。第二行将*遵循了* ***`SettingsManageable` 自定义类型****添加*到了 URL 末尾，还加上了 “.plist” 扩展，然后我们将其返回。 |
There was a problem hiding this comment.
97 - 118 行的文字被加上了错误的 斜体 标签，请修正
There was a problem hiding this comment.
这个地方我试了试似乎 markdown 不能处理这种斜体嵌套多个粗体的情况。于是就去掉了斜体的样式，只保留了粗体。
| 如果 `loadUsingSettingsFile()` 方法返回 true，那么执行则会走到里面的 `else`，并且方法会返回 true。另一种情况，如果恢复初始设置成功了，则会返回 `load()` 方法的执行结果。无论初始设置是如何被定义的，是直接设置给属性，还是应用包中的属性列表文件，上面的实现都会正常工作。你或许会想为了实现一个重置的功能费这么多功夫是否值得，但相信我，值。随着时间的推移，你绝对会需要这个功能，而那时候就可没有那么多时间来实现了！ | ||
|
|
||
| # 将属性列表内容当作字典 | ||
| 所有在 `SettingsManageable` 协议中的方法，都是为遵循了协议的类或结构体，提供对应的保存和加载的方法。数据保存是通过 `PropertyListEncoder` 编码后存储为属性列表文件，然后通过 `PropertyListDecoder` 来解码。诚然，与属性列表数据和其相关的类打交道的次数，并不像遇到 JSON，`JSONEncoder` 和 `JSONDecoder` 那么多。所以借此机会，那就让我们来更进一步地使用它，来看看怎么使用 `PropertyListSerialization` 类以及如何将属性列表作为字典类型获取。 |
There was a problem hiding this comment.
所有在 SettingsManageable 协议中的方法，都是为遵循了协议的类或结构体，提供对应的保存和加载的方法。
=>
上述这些 SettingsManageable 协议的方法，为遵循了协议的类或结构体提供了保存与加载的能力。
| 如果 `loadUsingSettingsFile()` 方法返回 true，那么执行则会走到里面的 `else`，并且方法会返回 true。另一种情况，如果恢复初始设置成功了，则会返回 `load()` 方法的执行结果。无论初始设置是如何被定义的，是直接设置给属性，还是应用包中的属性列表文件，上面的实现都会正常工作。你或许会想为了实现一个重置的功能费这么多功夫是否值得，但相信我，值。随着时间的推移，你绝对会需要这个功能，而那时候就可没有那么多时间来实现了！ | ||
|
|
||
| # 将属性列表内容当作字典 | ||
| 所有在 `SettingsManageable` 协议中的方法，都是为遵循了协议的类或结构体，提供对应的保存和加载的方法。数据保存是通过 `PropertyListEncoder` 编码后存储为属性列表文件，然后通过 `PropertyListDecoder` 来解码。诚然，与属性列表数据和其相关的类打交道的次数，并不像遇到 JSON，`JSONEncoder` 和 `JSONDecoder` 那么多。所以借此机会，那就让我们来更进一步地使用它，来看看怎么使用 `PropertyListSerialization` 类以及如何将属性列表作为字典类型获取。 |
There was a problem hiding this comment.
所以借此机会，那就让我们来更进一步地使用它
那就 去掉
| 如果 `loadUsingSettingsFile()` 方法返回 true，那么执行则会走到里面的 `else`，并且方法会返回 true。另一种情况，如果恢复初始设置成功了，则会返回 `load()` 方法的执行结果。无论初始设置是如何被定义的，是直接设置给属性，还是应用包中的属性列表文件，上面的实现都会正常工作。你或许会想为了实现一个重置的功能费这么多功夫是否值得，但相信我，值。随着时间的推移，你绝对会需要这个功能，而那时候就可没有那么多时间来实现了！ | ||
|
|
||
| # 将属性列表内容当作字典 | ||
| 所有在 `SettingsManageable` 协议中的方法，都是为遵循了协议的类或结构体，提供对应的保存和加载的方法。数据保存是通过 `PropertyListEncoder` 编码后存储为属性列表文件，然后通过 `PropertyListDecoder` 来解码。诚然，与属性列表数据和其相关的类打交道的次数，并不像遇到 JSON，`JSONEncoder` 和 `JSONDecoder` 那么多。所以借此机会，那就让我们来更进一步地使用它，来看看怎么使用 `PropertyListSerialization` 类以及如何将属性列表作为字典类型获取。 |
There was a problem hiding this comment.
来看看怎么使用 PropertyListSerialization 类以及如何将属性列表作为字典类型获取。
第一个 来 字去掉，和前面的 来 不要连着用
| # SettingsManageable 协议实战 | ||
| 是时候来用用我们完成的实现了。在启动项目中你可以找到两个测试文件，分别是叫做 *AppSettings* 的类和叫做 *PlayerSettings* 的结构体。我们将会通过它们来看看我们的协议在实践中如何使用的！ | ||
|
|
||
| 首先从 *AppSettings.swift* 文件开始，`AppSettings` 类中模拟了几个能在真实应用中找到的设置选项。在这个类中，你马上会注意这个类有一个静态的共享实例，以及一个私有的初始化方法，它是个符合 [***单例***](https://en.wikipedia.org/wiki/Singleton_pattern) 的类。我选择这种方式的理由很简单：当处理应用的设置时，创建多个实例来持有这些设置，可能不是一个好的主意，会存在数据重载的风险。而使用单例时，因为只有一个实例，搞坏设置数据的风险被降到了最低。然而如果你不同意这种方案，可以自行移除 `init()` 方法的 `private`关键字，删除静态共享实例，然后在需要的时候，像其他普通的类一样初始化创建实例。我们会在下一个例子中看到如此处理的 `PlayerSttings` 结构体。同时你会注意到设置的初始值是默认的属性值。 |
|
|
||
| 可以看到在这种情况下无需使用 `do-catch` 声明。由于我们将其标记了 `throws` 关键字，这个方法会将任何可能发生的错误传递出去。这意味着每一次调用它我们都需要对其进行异常的检查。我个人觉得这不太实用，我的期望是能够尽量轻松，并且没有额外操作的情况下更新配置。一个能够表示更新成功与否的标记应该足够了，所以我会选择那个方案。然而，为了让你方便，我把这个解决方案也提供给你，供你来选择。注意接下来这个方案不会再出现了，不过你仍然可以通过我刚刚展示的方式来将其转化成这个方案。 | ||
|
|
||
| > 注意：想要了解更多关于错误处理的内容？看看 [这个文档](https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html) 吧！ |
|
所有的标题格式都不对，少了一个 # |
|
第四次修订好啦，请 @WAMaker 再看看～ |
WAMaker
approved these changes
Feb 21, 2020
* 翻译：【中】The usefulness of typealiases in swift * First revision: the usefulness of typealiases in swift * Second revision: the usefulness of typealiases in swift * Third revision: the usefulness of typealiases in swift
* 【feature】新增翻译文件 * 【feature】根据梁大修改意见修改 * 【feature】修复部分翻译不够好的句子 * 【feature】根据思琪建议修改 Co-authored-by: 马楚鸿 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
这篇文章对应的 Issue 链接是：#264
本文的大致阅读时长：[ 20 ] 分钟。（这里按照你的主观感受填写即可，不需要非常准确，主要给读者一个参考）
PR Checklist:
请校对同学帮忙校对。