swift - Swift 模块/类如何解决缺少对 "protected"成员的语言支持的问题？

Question

我遇到这样一种情况，我在模块中定义了一个可重用的基类，我想提供某些只能由子类而不是该子类的外部用户调用的函数。

我正在编写一个框架并将其打包为 Swift 模块。我的框架的一部分包括一个基类，可以对其进行子类化以添加功能，但是派生类也有更进一步的外部目的。想象一下定义一种新的 View :它派生自 UIView 或 NSView，然后提供额外的逻辑，然后由另一方实例化。

在这种情况下，我是定义类似于 UIView 的类的人，该类旨在被子类化，并且随之而来的是许多私有(private) UIView 内部东西，比如测量、安排，谁知道呢，内部的东西。

关键是，这个新 View 类的最终用户不想看到支持子类化的体系结构的内部结构，那些应该完全在子类所代表的黑盒子里。

令我震惊的是，这在 Swift 中是不可能的。

我真的不明白为什么 Swift 摆脱了 protected 访问控制。 According to Apple ，我只想公开给子类的函数“在子类之外并不是很有用，所以保护并不重要”。

我错过了什么吗？这是 Swift 根本无法支持的一整类设计模式吗？

我想到的一个想法是，我或许可以将我类(class)的公共(public)-公共(public)和私有(private)-公共(public)部分分成两部分，也许使用协议(protocol)，公共(public)-公共(public)用户只能看到公共(public)协议(protocol)和“私有(private)” "公共(public)用户也会看到“私有(private)”协议(protocol)。唉，这似乎是为了过去免费的东西而进行的大量工程。

Answer 1

FWIW — 自从 Swift 中有访问控制之前，我一直在要求在 Swift 中提供更好的访问控制(包括 protected)。现在，在我们被告知尝试使用 Swift 方法进行访问控制 3.5 年之后，Swift 一直是我近 3 年的主要语言，我仍然认为访问控制范式很笨拙，无法对易于理解的概念进行建模几乎所有相似的语言。

对我来说最大的缓和因素是 Swift 让我在 95% 的时间里不再使用继承和子类化，我认为这是一件好事。所以这个问题出现的次数比其他情况少。但是对于您所描述的情况，没有一种等效的方法可以仅使用协议(protocol)和协议(protocol)扩展来完成您正在做的事情，因此您要么用可能有害的内部细节污染公共(public) API，要么使用一些解决方法(比如下一个)它具有尽可能少的公共(public) API 暴露，并以样板和笨拙为代价模拟您想要的东西。

也就是说，我采用的方法在某种程度上受到了 Objective C 的启发，其中也没有真正的 protected 访问控制，但约定是声明一个公共(public) API header (客户端代码将导入该 header )和引用)和一个特殊的“+Subclassing” header ，只有子类才会在其实现中导入，使它们能够看到非公共(public)消费的内部结构。

在 Swift 中，这也不是直接可能的，但是给定一个这样的类:

open class SomeClass {
    private var foo: String
    private var bar: Data
    public init(){
        foo = "foo"
        bar = Data()
    }
    private func doInternalThing() {
        print(foo)
    }
}

您可以通过扩展添加一个嵌套的“ protected ”包装器(必须与您的类声明在同一个文件中)，它采用类(或子类)的实例并将 protected 级别的内部结构公开为一种代理人:

// Create a nested "Protected" type, which can accept an instance of SomeClass (or one of its subclasses) and expose the internal / protected members on it
public extension SomeClass {
    public class Protected {
        unowned private var someClass: SomeClass
        public var foo: String {
            get {
                return someClass.foo
            }
            set {
                someClass.foo = newValue
            }
        }
        public init(_ someClass: SomeClass) {
            self.someClass = someClass
        }
        public func doInternalThing() {
            someClass.doInternalThing()
        }
    }
}

在框架之外，在客户端应用程序中， protected 成员在这样的子类中访问:

class SomeSubclass: SomeClass {
    private lazy var protected: SomeClass.Protected = { SomeClass.Protected(self) }()
    func doSomething() {
        protected.foo = "newFoo"  // Accesses the protected property foo and sets a new value "newFoo"
        protected.doInternalThing() // Prints "newFoo" by calling the protected method doInternalThing which prints the foo property.
    }
}

这种方法有利也有弊。缺点主要是您需要编写的样板数量，以便将所有属性和函数从 Protected 包装器映射到实际的类实例，如上所示。此外，无法避免这样一个事实，即消费者会将 SomeClass.Protected 视为一种公开可见的类型，但希望很明显它不应该被使用，并且很难随意使用它，所以它不会发生。

优点是在创建子类时没有太多样板文件或给客户带来痛苦，并且很容易声明一个惰性的“ protected ”var 来获得所需的 API。非子类偶然或无意中偶然发现或使用此 API 的可能性很小，而且它大部分是根据需要隐藏的。 SomeSubclass 的实例不会在代码完成或外部代码中显示任何额外的 protected API。

我鼓励任何其他认为访问控制——或者在这种情况下，API 可见性和组织——比现在的 Swift 更容易的人通过 Swift 论坛、Twitter 或 bugs.swift 让 Swift 团队知道。组织。