[Interview Questions] Access Control in Swift 4.0/4.1
Here’s an interview question that I start to hear more often on iOS interviews:
What is the difference between
private,public,internal,open, andfileprivateaccess levels in Swift 4.0/4.1?
This is one of the fundamental Swift/iOS questions. In this article, as usual, we’ll go through the reasoning behind the question, the expected answer, and the answer that could raise a red flag for your interviewer.
Reasoning:
With the recent changes to access control in Swift 4.0/4.1, it is important for iOS developers to know about the new access control keywords such as fileprivate and to be able to utilize them properly at the right time. Access control is one of the cornerstones of object-oriented programming languages such as Swift, and it allows you to encapsulate data and set visibility of data and methods.
Expected Answer:
Good OOP design restricts access to data, methods, and types, exposing public interfaces and hiding unimportant implementation details. Encapsulation helps you abstract things out and communicate with parts of your application or third-party code through a clearly defined interface.
In Swift encapsulation is achieved by using the following five access control keywords: private, fileprivate, internal, public, and open. These access levels either restrict or open access within the scope of a file or module. Let’s take a look at each of them from the most restrictive, private, to the least restrictive, open.
Private access is the most restrictive. If you define something as private it means it is private to that declaration scope and can’t be accessed from the outside. For example, let’s say you have a class A and it has a private property b. Only methods inside class A have access to property b, no one else. The one exception to this rule is *extensions* defined in the same file. If you create an extension A in the same file where class A is defined, then you’ll be able to access property b within that extension. Subclasses and extensions in different files will not. Use private to hide implementation details.
Fileprivate access is the second-most restrictive. Defining something as fileprivate means that it will be only accessible within the scope of the file where it was declared. It is a very handy way of creating helper objects/types that help one of the public/internal classes you declared but do not need to be exposed to the rest of the app.
Internal access is the default access level that will be set if you do not explicitly state otherwise. Internal means that this thing can be used anywhere within the module it was defined. Basically if you’re building an app, internal means it will be available anywhere in that app. If you’re building a library/framework, internal means it will be available within that library/framework but not outside from the app that uses the library.
Public access means that something can be accessed not only within the defining file and module but also from the outside module that imports the one where it was defined. Effectively, public declares a public interface for the module. For example, let’s say you have a framework that exposes a public class A as its public interface. This means that whoever says import MyModuleWithClassA will have access and can instantiate A. But A can be subclassed only within the MyModuleWithClassA, anyone who imports it can only use it, not subclass.
Open access means that something is public and can also be subclassed not only within the module where it was defined but also by whoever imports it.
Red Flag:
What could raise a red flag for an interviewer is for a developer to completely disregard the importance of access levels and go with the default internal access level for everything. A lot of developers do this, and it makes two things glaringly obvious: they do not think about the importance of hiding implementation details for encapsulation, and they never break their apps down into libraries/frameworks/modules for better architecture.
Conclusion
Access levels are very important for designing your app well. It’s a fundamental Swift feature but has a huge high- and low-level impact if it is used right or disregarded.
