Access control and protected in Swift

This article focuses on access control and protected in swift, and this article explains why Swift does not have the protected option, and friends who need it can refer to

The original text is renewed and the book is folded for the first time.

Many other programming languages have a "protected" setting that restricts certain class methods to be used only by its subclasses.

After Swift has supported the access control, the feedback we received was very good. And some developers ask us: "Why does Swift not have a protected-like option?"

When we were designing different levels of swift access control, we thought there were two main scenarios:

In an app: Hide the private details of a class.

In an open source framework: Do not let the app that imports this framework casually touch the internal implementation details of the framework.

The above two common situations correspond to the two levels of private and internal.

and protected is equivalent to the access control and inheritance characteristics of the mix, the access control level set up a dimension, make it more complicated. Even if protected is set, subclasses can access the so-called "protected" API through new open methods and new attributes. On the other hand, we can rewrite a method in various places, and the so-called protection does not provide the optimization mechanism. This setting is often made unnecessarily restrictive one protected allows subclasses, but also prohibits all other classes (including those that help subclasses implement certain functions) from contacting members of the parent class.

Some developers point out that Apple's framework sometimes separates the APIs used for subclasses. Is this the protected? We found that these methods generally fall into the following two situations: one is that these methods are not useful for classes other than subclasses, so there is no need for strict protection (for example, classes that help implement certain functions). The second is that these methods are designed to be rewritten instead of being used directly. For example, DrawRect (_:) is a method used on uikit basis, but it cannot be applied outside of Uikit.

Besides, if there is protected, how does it interact with extension? Can a class of extension contact its protected members? Can the extension of a subclass contact the protected member of the parent class? Does the location of the extension declaration affect the access control level? (Complicated to cry, isn't it?)

The design of access control also follows the usual practices of objective-c developers, both inside and outside of Apple. Objective-c methods and properties are generally stated in the. h header file, but can also be written in the. m implementation file. If there is a public class that wants to make certain parts of it available only within the framework, the developer will typically create another header file for internal use. The above three access levels correspond to the public,private and internal in swift.

Swift's access control level is independent of inheritance and is a single dimension, very clear. We believe that this pattern is simpler and satisfies the most important requirement: isolating the implementation details of a class, or a framework. This may be different from what you've used before, but we encourage you to try.