| < What’s the point of static properties and methods in Swift? | Why does Swift have both classes and structs? > |
What’s the point of access control?
Updated for Xcode 15
Swift’s access control keywords let us restrict how different parts of our code can be accessed, but a lot of the time it’s just obeying the rules we put into place – we could remove them if we wanted and bypass the restrictions, so what’s the point?
There are a few answers to that, but one is particularly easy so I’ll start there: sometimes access control is used in code you don’t own, so you can’t remove the restriction. This is common when you’re building apps with Apple’s APIs, for example: they place restrictions about what you can and cannot do, and you need to abide by those restrictions.
In your own code, yes of course you can remove any access control restrictions you put in place, but that doesn’t make it pointless. Access control lets us determine how a value should be used, so that if something needs to accessed very carefully then you must follow the rules.
Previously I’ve mentioned Unwrap, my Swift learning app, and I want to use another example from there. When users learn different parts of Swift, I store the name of the thing they learned in a private Set inside a User struct, declared like this:
private var learnedSections = Set<String>()It’s private, which means no one can read or write to it directly. Instead, I provide public methods for reading or writing values that should be used instead. That’s intentional, because learning a section needs to do more than just insert a string into that set – it needs to update the user interface to reflect the change, and needs to save the new information so the app remembers it was learned.
If I hadn’t made the learnedSections property private, it’s possible I might forget and write things to it directly. That would result in my UI being inconsistent with its data, and also not saving the change – bad all around!
So, by using private here I’m asking Swift to enforce the rules for me: don’t let me read or write this property from anywhere outside the User struct.
One other advantage to access control is that it lets us control how other people see our code – known as its “surface area”. Think about it: if I gave you a struct to use and it had 30 public properties and methods, you might not be sure which ones are there for you to use and which ones are really just for internal use. On the other hand, if I mark 25 of those as private then it’s immediately clear that you shouldn’t be using them externally.
Access control can be quite a thorny issue, particularly when you take into account external code. So, it’s not a surprise Apple’s own documentation on it is quite long – you can find it here: https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html
SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
