1

I've read the section concerning access control in the iBook published by Apple, but I'm not understanding why is that needed or useful.

Why would I need to hide parts of my code to the other code files in my app using private?

dieortin
  • 514
  • 5
  • 16
  • really, really, overly broad question that isn't at all specific to swift. – sevenseacat Aug 14 '14 at 03:57
  • I can't find a *great* answer to this (general) question on SO already, which surprises me. There's a [question](http://stackoverflow.com/questions/20895101/what-is-the-purpose-of-access-modifiers), all right, but it doesn't look like it got a lot of attention. And there's a [history](http://stackoverflow.com/questions/1334451/history-of-access-control-modifiers-such-as-public-private-protected), but it doesn't go much into the *why* of them. Did I miss a good one? – Matt Gibson Aug 14 '14 at 06:18
  • 1
    I think this is a fine question, and actually provides an opportunity to address a bunch of misconceptions about why access control is valuable. Many programmers working on apps think of it as entirely idiot-proofing, but there's so much more to it than that. – Catfish_Man Aug 14 '14 at 18:36

2 Answers2

9

Access modifiers are, above all, a way to communicate intent about how your API should be used. By marking something private, it no longer shows up as part of that type's interface, thereby avoiding confusion about which variables and functions are intended for use and which are merely internal implementation details.

For framework authors (like Apple, but also in any large team environment), access modifiers also provide a way of controlling whether something must be supported going forward. If something is private, it can't be used by programs using the framework in question, so future versions of the framework can change or remove it without fear of breaking existing apps.

Finally, by providing guarantees about how a function or variable is used, access modifiers allow the compiler to make optimizations it could not otherwise make. All private things can be considered 'final' for example, which can dramatically improve performance by allowing inlining and avoiding dynamic dispatch.

Catfish_Man
  • 41,261
  • 11
  • 67
  • 84
1

When writing a class there are actions you want to provide to users of the class. These are public methods. When implementing these there will be many smaller methods that these use, they are not designed to be used by other classes and by making them private this is insured. Further, because they have a small number if users (probably one) it is easier to insure their correctness. Later, one can modify these private methods, re-name them, delete them and create new ones as needed be confident that no user of the class will be affected because no other class can be using them.

This method of writing code is called "Write To The Interface, not to the implementation". It is one of the few principles we have.

What @Catfish_Man says is also true but this is just as applicable to one-man-projects. It allows me to know when I have to consider how other class instances might be affected by changes or that I can freely make changes. Note: One school of development says that methods should be small, by small I mean around seven lines of code each. Obviously there will be lots of methods and most should be private as they are not used by amy other class.

zaph
  • 111,848
  • 21
  • 189
  • 228