Access Control and protected in Swift

Access Control and protected in Swift

This article mainly introduces access control and protected in Swift. This article mainly explains why Swift does not have the option similar to protected. For more information, see

Continue the original article, and fold the book for the first time.

Many other programming languages have a "protected" setting, which can restrict some class methods to be used only by its subclass.

After Swift supports access control, all of you have provided us with great feedback. Some developers ask us: "Why does Swift have any option similar to protected ?"

When designing different levels of Swift access control, we think there are two main scenarios:

● Hide private details of a class in an APP.

● In an open-source framework: do not allow the APP to import this framework to access the internal implementation details of the framework.

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

Protected is equivalent to mixing access control and inheritance features, and adds a dimension to the access control level setting to complicate it. Even if protected is set, the subclass can still access the so-called "protected" API through new public methods and new attributes. On the other hand, we can rewrite a method in various places, but the so-called protection does not provide an optimization mechanism. This setting is usually unnecessary. A protected allows subclass, but disallows all other classes (including those that help subclass implement some functions) to access members of the parent class.

Some developers point out that apple's framework sometimes separates sub-classes with APIs. Does protected work at this time? After our research, we found that these methods generally fall into the following two situations: first, these methods are useless to classes other than subclass, therefore, no strict protection is required (for example, the class mentioned above to assist in implementing certain functions ). Second, these methods are designed to be rewritten, rather than directly used. For example, drawRect (_ :) is the method used based on UIKit, but it cannot be applied outside of UIKit.

In addition, if protected exists, how does it interact with extension? Can the extension of a class access its protected members? Can the extension of a subclass access the protected members of the parent class? Does the location of the extension declaration affect the access control level? (It's complicated to cry, isn't it ?)

The Design of access control also follows the general practices of Objective-C developers (including those inside and outside apple. Objective-C methods and attributes are generally declared in the. h header file, but can also be written in the. m implementation file. If you want to set some parts of a public class to be available only within the Framework, developers generally create another header file for internal use. The above three access levels correspond to the public, private, and internal in Swift.

The access control level of Swift has nothing to do with inheritance. It is single-dimensional and clear. We believe that this mode is more concise and meets the most important requirement: to isolate the implementation details of a class or framework. This may be different from what you used before, but we encourage you to try it out.