The original text is continued, the first chapter of the book.
Many other programming languages have a "protected" setting that can restrict certain class methods to be used only by its subclasses.
After Swift supports access control, everyone’s feedback has been very good. And some developers asked us: "Why does Swift have no protected options?"
When we were designing different levels of Swift access control, we thought there were two main scenarios:
●In an APP: Hide private details of a certain class.
●In an open source framework: APPs that do not allow importing this framework are to be exposed to the internal implementation details of the framework.
The two common situations above correspond to the two levels of private and internal.
Protected is equivalent to mixing access control and inheritance features, adding a dimension to the access control level setting, complicating it. Even if protected is set, subclasses 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 often makes unnecessary restrictions. A protected allows subclasses, but prohibits all other classes (including those that help subclasses implement certain functions) from contacting members of the parent class.
Some developers pointed out that the apple framework sometimes separates the APIs used for subclasses. Isn’t protected useful at this time? After research, we found that these methods generally fall into the following two situations: First, these methods are of no use to classes other than subclasses, so they do not require strict protection (such as the classes that assist in implementing certain functions mentioned above). Second, these methods are designed and rewritten, rather than used directly. For example, drawRect(_:) is a method used on UIKit, but it cannot be applied outside UIKit.
In addition, if protected is available, how will it interact with extension? Can an extension of a class contact its protected members? Can a subclass's extension contact the protected members of the parent class? Does the location declared by extension have an impact on the access control level? (It's so complicated that I'm going to cry, right?)
The design of access control also follows the conventional practices of Objective-C developers (including inside and outside the apple). Objective-C methods and properties are generally declared in the .h header file, but they can also be written in the .m implementation file. If there is a public class that wants to set some parts of it to be only available within the framework, the developer will generally create another header file for internal use. The above three access levels correspond to public, private and internal in Swift.
Swift's access control level has nothing to do with inheritance, it is single-dimensional and very clear. We believe that this model is simpler and meets the main requirement: isolate and protect the implementation details of a class or a framework. This may be different from what you have used before, but we encourage you to give it a try.