Access control in Swift and protected

The original text continued, the first fold of the book.

Many other programming languages have an "protected" setting that limits certain class methods to be used by its subclasses.

After Swift supported access control, we got a lot of feedback. Some developers asked us, "why doesn't Swift have an protected option?"

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

● in 1 APP: hide the private details of a class.
● in an open source framework: do not allow the import of APP of this framework, touch the internal implementation details of the framework.

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

protected, on the other hand, mixes access control and inheritance into one, adding one dimension to the hierarchy of access control and complicating it. Even with protected set, subclasses can access the so-called "protected" API through new exposure methods and new properties. 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 often an unnecessary restriction. 1 protected allows subclasses, but prohibits all other classes (including those that help subclasses achieve certain functions) from touching members of the parent class.

Some developers have pointed out that the apple framework sometimes separates out API for subclasses. Wouldn't protected be useful then? When we looked at them, we found that these methods 1 generally fall into one of two categories: 1 is that they don't work for classes other than subclasses, so they don't need strict protection (such as the classes above that help implement certain functions). 2 is that these methods are designed to be rewritten, not used directly. For example, drawRect(_:) is a method based on UIKit, but it cannot be applied outside of UIKit.

Besides, if you have protected, how does it interact with extension? Can the extension of a class contact its protected members? Can extension of a subclass contact protected members of the parent class? Does the location of the extension declaration affect the access control level? (complicated enough to cry, right?)

The access control design also follows the usual practices of the developers of Objective-C (both inside and outside apple). The Objective-C method and property 1 are declared in the.h header file, but can also be written in the.m implementation file. If you have a public class and want to make parts of it available only within the framework, developer 1 will create another header file for internal use. The three access levels above correspond to public, private and internal in Swift.

The access control level of Swift is independent of inheritance and is one dimensional and very clear. We think this pattern is more concise and meets the primary need: to isolate and protect the implementation details of a class or framework. It may be different from what you've used before, but we encourage you to give it a try.