当开发一个应用程序时，我的方法（无论正确与否）是将逻辑分离到一个框架（工具包）中，原因是相当直接的。- 我喜欢能够隔离测试逻辑--我喜欢它迫使我忘记UI和任何UI假设--我喜欢我可以自由地使用一个单独的UI来创建应用程序......这取决于设备（iPhone，Watch......Apple TV......命令行实用程序）。
因为我喜欢在一个单独的框架中的逻辑......我已经引入了一个复杂的访问修饰符（Public, Internal, Private），用于类，结构，枚举，方法，属性。
我最头疼的是 属性 (特别是实体的属性)我更倾向于不将设置器暴露给框架的消费者(即UI应用)。private(set) var nameOfProperty 方法。然而在框架的实体中，这对我来说不是一个选项。
所以对于框架来说，我更愿意返回一个...的方法。议定书 的界面，描述了一个 实体 ...即它的可写属性，它的只读属性和它的可访问方法。
我们(Swift开发者)一直被鼓励走根据行为命名协议的路线.但是，.例如，一个人的行为，他是一个很好的例子。足球队选拔 我不希望来回传递符合 "球员"、"经理"、"夹具 "的东西。我想来回传递一个 "球员"、"经理"、"夹具"（消费者理所当然地期望）。
我应该给我的 实体 (假设它符合一个俗称的协议) ? 可以理解的是，我们不能有一个叫做 protocol Player 和 class Player
一些建议的想法
理念1: 在框架内使用下划线（我最有可能采用的方法），例如：在框架内使用下划线。
public protocol Player {
public var name: String { get }
}
public class _Player: Player {
..
}
理念2: 不要使用协议，而是使用计算的属性（不是首选），如
public class Player {
private var _name: String
public var name: String {
get {
return _name
}
}
理念3: 不要使用协议，因为你是唯一的消费者，那就相信自己，把一切都公开化"■▄。
public class Player {
public var name: String
}
理念4: 在框架中使用一个替代的名字（有点像下划线），例如："Framework"。
public protocol Player {
public var name: String { get }
}
public class PlayerEntity: Player {
..
}
or
public class PlayerImpl: Player {
..
}
or
public class PlayerObj: Player {
..
}
就个人而言，我会选择 Player: PlayerProtocol除非你将更频繁地使用该协议。在标准库中有一些这样的例子，如 StringProtocol 和 IteratorProtocol.