We explore some special types of properties and how access control works in Swift.

Properties and Access Control

When writing a struct, class, or enum it may be helpful to divide the code into several different sections.  By using an **extension**, you can continue writing the definition of a struct, class, or enum anywhere in your codebase.

```swift
struct Cat {
    let name: String
    let age: Int
}

extension Cat {
    static let famousCats = [
        Cat(name: "Stubbs", age: 20), 
        Cat(name: "Sweet Tart", age: 12), 
        Cat(name: "Hank the Cat", age: 13)
    ]
}

print(Cat.famousCats.count) // prints 3
```

Code that’s written in an extension will behave exactly the same as if it was defined in the original struct.  You can even extend structs, classes, and enums from the Swift Standard Library!

```swift
extension Int {
    var isEven: Bool {
        isMultiple(of: 2)
    }
}
 
let catCount = 3
print(catCount.isEven) // prints false
```

The only thing that you can’t do in extensions is create stored properties:

```swift
struct Cat {
    let name: String
    let age: Int
}

extension Cat {
    var numberOfLegs: Int // ERROR: Extensions must not contain stored properties
}
```

This restriction ensures that adding an extension will never cause your code to not compile by adding new requirements.  Instead, you can add computed properties:

```swift
struct Cat {
    let name: String
    let age: Int
}

extension Cat {
    var numberOfLegs: Int { return 4 }
}
```

Let's try adding an extension to our `Office`!

Extensions

Great work! We’ve expanded on our understanding of structures and properties and learned about access control, adding a lot of useful tools to our Swift toolbelt. Here are the key points we covered in this lesson:

* The boundaries for access control are modules, source files, and `structs`.
 * Public is the most permissive and allows access between modules. (useful for SDKs and frameworks)
 * Internal is the default level and allows access anywhere within a module.
 * File private allows access within a source file.
 * Private can only be used within the scope of a `struct`. (least permissive)
* Private properties are defined using the `private` syntax.
 * Memberwise initializers can’t access private properties, so you need to use default values, make them optional, or use the init method.
* Private methods use the same syntax as private properties and can only be called within the scope of the `struct` that defines them.
* Computed properties aren’t stored values, rather they are derived from other stored properties.
 * Can be read-only. (only have getter method)
 * Can set them, in which case you change the underlying properties from which they are derived.
* Property observers are built in methods that get called when properties are set.
 * didSet gives us the old value.
 * willSet gives us the new value.
* Properties can have a more restricted access level to set vs. get. 
* Type properties are defined independently from any particular instance of a structure.



Review

**Public**
We’ll start with `public`, the most open level, which grants access to a property or method from inside or outside the module. Relating it to the company analogy, since modules are companies, public information can be shared between companies. This level is typically used when creating frameworks so that modules that import the framework can access its properties and methods. 

**Internal**
The next level, in order of least to most restrictive, is `internal`. This is the default level for all properties and methods, so it is active if no access level is specified. Internal grants access to properties and methods within a module. So in our company analogy, internal would be the information that can be shared with anyone within the company. Having everything internal by default is convenient because you can easily access properties and methods across source files, but there may be cases where this could lead to problems, so we might want to impose a more restricted level of access control.

**Fileprivate**
Fileprivate is the next level, and it grants access to properties and methods within a source file. Remember source files are the divisions of our company, so this is the information that can be shared within a given division between any office. 

**Private**
Finally, the most restrictive level of access is `private`, which restricts access to a property or method within a structure. Since structures are the offices in our analogy, this is information only to be shared within an office of a division of a company. 

**Open**
Additionally, there is `open` which is similar to `public` in that it allows access from other modules. However, it only applies to classes and class members. We will learn about classes in another lesson, but `open` is an access level you should be aware of. 

Don’t worry if this is all still a bit abstract, we will build on the company analogy throughout the lesson to illustrate the value of access control when developing Swift applications.

Levels of Access

In this lesson, we will explore some special types of properties we can use in structures as well as how access control works in Swift, and how to apply it in the context of structures. 

Let’s begin by diving into access control! As the name implies, it allows us to control access to properties and methods within our code. By implementing different levels of access control on properties and methods, we determine which other parts of the code can read their values, write to them, and execute methods. Access control helps us protect sensitive information from being read or modified, making our code safer and more robust.

It’s important to understand the boundaries that define the scope of access control. These boundaries are delineated by modules, source files, and finally `struct`,  `class`, or `enum` definitions within source files. We will cover classes in a later lesson; for now, we will focus on structures. 

A module is an entire app or framework. Technically, it is defined as a [build target](https://developer.apple.com/library/archive/featuredarticles/XcodeConcepts/Concept-Targets.html) for the Swift compiler. Your app may consist of one or more modules; they are like building blocks and can be integrated using the `import` keyword at the top of a source file. As previously we saw in the Libraries article, Foundation is an example of a module that is very commonly imported to Swift applications.

Source files are exactly what they sound like. They are the files that your source code is contained in. A module typically consists of multiple source files. 

To help us understand the purpose and mechanics of access control, let’s think about how information is managed in a company. In a typical large company, we might have some information that is shared with the public, some information that is for anyone who works for the company, some information that can only be shared within a division of the company, and some information that can only be shared within an office of a division. In this analogy, modules are companies, source files are divisions, and structures are offices. Take a look at the image on the right to get a visual of this analogy. Let’s use this analogy to drill down into each level of access control. 

Three company office buildings demonstrating different types of access control.

Introducing Access Control in Swift

Oftentimes, we find ourselves being more concerned with data being changed and not so concerned about who can read it. When this is the case, it is possible to implement a private setter. A private setter allows us to limit write access to within the scope of the `struct` but still allow the property to be read outside of the `struct`. 

We use the `(set)` keyword when we want to declare a private setter: 

```swift
struct Cat {
    private(set) var numberOfLives : Int
}
```

In this example, we declare the setter to have private level access, while the getter will be the default `internal` level access. Note that we could have also declared the `numberOfLives` variable like so:

```swift
struct Cat {
    public private(set) var numberOfLives : Int = 9
}

var scrambles = Cat()

// Prints: 9
print(scrambles.numberOfLives)

// This causes a compiler error due to invalid access
scrambles.numberOfLives = 10


```

This gives the getter for `numberOfLives` public level access, while the setter has private level access. Any combination of access levels can be declared, as long as the setter has a lower access level than the getter. For example `open fileprivate(set)` is a valid access level, while `private internal(set)` would be an invalid access level.


Implementing a Private Setter

Up until this point, we have always associated properties with an _instance_ of a `struct`. However, it is also possible to define a property that is associated directly with the `struct` itself. Such a property is known as a _type property_.

A type property can be useful in cases where there is some value that we want to be consistent regardless of any instance of our `struct`. This might be a constant value, but it can also be a variable. Usually, the value is associated with that type of object for a specific logical or informational reason. For example, `Double.pi` is a type property that retrieves the value of pi from the built-in `Double` structure in Swift. 

Let’s say we want to create a variable type property that stores the value of `oldestCat`. It will be updated when a specific cat breaks the age record, but it will hold true across all cats. We define a type property using the `static` keyword: 

```swift
struct Cat {
    static var oldestCat : Int = 0
}
```

Since type properties aren’t tied to any instance of the `struct`, we use dot syntax on the type itself to access them: 

```swift
Cat.oldestCat = 38
print("So far the oldest cat we have seen is \(Cat.oldestCat) years old.")
// Prints: So far the oldest cat we have seen is 38 years old.
```

Methods can also be declared as `static`.  These are called on the class, structure, or enumeration itself rather than an instance.

```swift
struct Cat {
    static func displayDescription() {
        print("Cat's are great pets!")
    }
}

Cat.printDescription() // prints Cat's are great pets!
```


Defining a Type Property

There is another way we can access private properties inside of a structure: computed properties. Computed properties are a special type of property that don’t actually store a value directly, rather use other properties and constants to compute and return a value. 

Syntactically, computed properties look more like methods than properties. We define a getter and optionally, a setter, for each computed property. A _getter_, denoted by the `get` keyword, is used to retrieve the value of a property. A _setter_, denoted by the `set` keyword, is used to set the value of a property. We’ll cover setters more in-depth in the following exercise. 

As you might suspect, the getter defines the value to return when we read the property. A computed property with only a getter is known as a read-only computed property. Here is an example of a read-only computed property:

```swift
struct Cat {
    private var numberOfLives: Int
    
    var doubledLife: Int {
        get {
            return numberOfLives * 2
        }
    }
}
```
* We declare `doubledLife` as an `Int` type.
* The brackets after the type give us a scope for the getter.
* The `get` keyword defines the getter.
* The `return` keyword ends the scope of the getter and returns a final value.

A read-only computed property can be handy in cases where you want to safely give read access to some property but want to be sure it can’t be modified. It should be noted that in the preceding example we are accessing a private property, but computed properties aren’t limited to private properties and can include properties of any access control level. We should also note that computed properties don’t have type inference; we must explicitly define their type.


Using Read-only Computed Properties

As we learned in the previous exercise, private is the most restrictive level of access control and can be applied to properties or methods. When we make a property private, we make it so that its value can only be read and written within the scope of the structure that contains it. 

Here is the syntax for creating a private property in a `struct`:

```swift
struct Cat {
   private var numberOfLives = 9
}  
```

Recall from the Structures lesson that a `struct` includes built-in memberwise initializers for properties that allow us to initialize instances without explicitly defining an `init()` method. However, private properties must have an explicit `init()` method in order to initialize their value when creating an instance. Otherwise, they must be optional or have a default value. 

Here is how we can use `init()` to create an initializer for the Cat `struct`: 

```swift
struct Cat {
    private var numberOfLives: Int

    init(numberOfLives: Int){
        self.numberOfLives = numberOfLives
    }
}

```

Since a cat can only lose one life at a time, it makes sense to make the `numberOfLives` property private, so it can’t be set directly. To enable the desired behavior of the Cat `struct`, we can implement a method that decrements `numberOfLives`:

```swift
struct Cat {
    private var numberOfLives : Int
    
    init(numberOfLives: Int){
        self.numberOfLives = numberOfLives
    }
    
    mutating func loseOneLife() {
        self.numberOfLives -= 1
        print(numberOfLives)
    }
}

var scrambles = Cat(numberOfLives: 9)
```

Recall from the previous Structures lesson that a `struct` method that changes the value of one of its properties must be marked `mutating`.

To decrement the private property, we simply call the `loseOneLife()` method, which has a default access level of `internal` since we didn’t specify one. This means we can call `loseOneLife()` on an instance of Cat from anywhere in the module:

```swift
scrambles.loseOneLife()

//outputs to console:
8

```
Ouch, sorry Scrambles! Don’t worry though, he landed on his feet 😸

Defining a Private Property

Another built-in feature of properties we might find useful is property observers. If access control is a lockset for our properties, property observers are the security cameras. Specifically, property observers let us know when observed properties are about to be, or have been modified.

There are two methods we can use to observe a stored property: `willSet` and `didSet`. As you might surmise, `willSet` is called right before we set the property, and `didSet` is called right afterward. 

In the scope of `willSet`, we are given the new value that the property will be set to, with the default parameter name `newValue`. Alternatively, we can define a custom name for the new value. Similarly, `didSet` gives you the old value that was previously assigned to the property, with the default name `oldValue`. Again, this can be overridden with a custom name. 

Let’s explore the syntax of property observers in our cat example:

```swift
struct Cat {
    private var numberOfLives : Int {
        willSet {
            print("Uh-oh, number of lives is changing to \(newValue)")
        }
        didSet(oldLives) {
            print("Welp, we don’t have \(oldLives) anymore")
        }
    }
    
    init(numberOfLives: Int){
        self.numberOfLives = numberOfLives
    }
    
    mutating func loseOneLife() {
        self.numberOfLives -= 1
    }
}

var scrambles = Cat(numberOfLives: 9)
scrambles.loseOneLife()
// Prints to console:
// Uh-oh, number of lives is changing to 8
// Welp, we don’t have 9 anymore
```

Note that we could have used a custom value for `willSet` as well, or we could have used the default value of `oldValue` in `didSet`. 


Using Property Observers

In addition to getting computed properties, there may be cases where it would be convenient to set the computed property as well. Recall that computed properties don’t store values directly, so we’ll actually be setting the underlying stored properties that our computed property is derived from. 

Going back to our feline structure, we have our computed property, `doubledLife`:

```swift
struct Cat {
    private var numberOfLives : Int
    
    var doubledLife : Int {
        get {
            return numberOfLives * 2
        }
    }
}
```

The easiest way to create the setter is to treat the getter as an algebraic equation: 

```swift
doubledLife = numberOfLives * 2
```

Now we solve for `numberOfLives` by dividing both sides by two:

```swift
numberOfLives = doubledLife / 2
```

We can complete the syntax for the setter using the `set` keyword, which also passes in the new value of the computed property. We can name this value anything, so let’s call it `newDoubledLife` for clarity:

```swift
struct Cat {
    private var numberOfLives : Int
    
    var doubledLife : Int {
        get {
            return numberOfLives * 2
        }
        set(newDoubledLife) {
            numberOfLives = newDoubledLife / 2
        }	 
    }
}

```
* The `set` keyword begins our setter definition
* The `newDoubledLife` parameter passes in the new value that we are assigning to `doubledLife` .
* We set the underlying stored property `numberOfLives` which `doubledLife` is derived from.

There are a few shorthand forms of computed properties you can use to make your code more concise and readable. The first one you should know is that read-only computed properties can omit the `get` keyword: 

```swift
var doubledLife : Int {
    numberOfLives * 2 
}
```
The second is that computed properties with a getter and setter can omit the `return` if the entire body of the getter is a single expression:

```swift
var doubledLife : Int {
    get {
        numberOfLives * 2
    }
    set(newDoubledLife) {
        numberOfLives = newDoubledLife / 2
    }	 
}

```
Finally, we can omit the passed parameter on the setter and use the default `newValue` that is provided to us:

```swift
var doubledLife : Int {
    get {
        numberOfLives * 2
    }
    set {
        numberOfLives = newValue / 2
    }	 
}
```

To recap: in order to set a computed property, we need to set all of the stored properties it’s derived from. We solve algebraically for the stored properties in terms of the computed property. Lastly, we learned about the shorthand forms we can utilize to make our code more concise.


Creating Setters for Computed Properties

There are some cases in which we may not want to expose methods outside of the scope of the structure such as when the method might access or modify some sensitive data. For those cases, we can use the `private` keyword to define a private method, in the same way we defined a private property: 

```swift
struct WizardCat {
    private func secretSpell() -> String {
        "Abracadabra"
    }
}
```

As we saw in the previous exercise, now only methods inside the scope of the structure can call `secretSpell()`. If we try to call the function outside of the scope of `WizardCat` we will encounter this error:

```error
error: 'secretSpell' is inaccessible due to 'private' protection level
```