Object Oriented Programming in Swift

Most of Apple’s frameworks have a object-oriented architecture. Before you start digging into iOS/MacOS development you should first understand object oriented programming and design patterns. In this article we will go through the basic notions and design patterns in order to get you started with app development.

Overview

Object-oriented programming (OOP) is a programming paradigm that represents the concept of “objects” that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.

There are 3 key aspects of object oriented programming:

Encapsulation means that objects keep their state information private. Rather than directly manipulating an object’s data, other objects send requests to the object, in the form of messages, some of which the object may respond to by altering its internal state.

Polymorphism means that objects of different classes can be used interchangeably. This is especially important, as it allows you to hook up classes at a later date in ways you didn’t necessarily foresee when those classes were first designed.

Inheritance means that objects of one class can derive part of their behavior from another (base or parent) class. Some object-oriented languages (C++, for example, but not Swift) allow multiple inheritance, where objects of one class can derive part or all of their behavior from multiple independent base classes.

Classes and Objects

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions, methods). In other words, a class is like a blueprint, it defines the data and behavior of a type.

class Button {
}

The definition above creates an empty class named Button. The only thing it can do is create new Button objects:

var button = Button()

In the example above button is an instance of the Button class.

Properties

Classes and instances can have associated values named properties.

class Square {
    var length: Int = 1
}

The Square class has a length property that has a default value of 1.

In order to create squares with a different length than 1 we need to write a custom initializer.

class Square {
    var length: Int = 1

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

var firstSquare = Square(length: 3)
println(firstSquare.length)

var secondSquare = Square(length: 10)
println(secondSquare.length)

if firstSquare.length < secondSquare.length {
    println("the small square has the length \(firstSquare.length)")
} else {
    println("the small square has the length \(secondSquare.length)")
}

Methods

Methods add behaviour to classes and instances.

class Square {
  var length: Int = 1


  func area() -> Int {
    return length * length
  }
}

The area() method computes the area of a Square instance when called. To call a method use the . notation.

var square = Square(5)

println(square.area()) // prints 25

sqare.length = 10

println(square.area()) // prints 100

Class Properties

The usual use of properties are instance properties, like the length of a Square. You can also have a properties. Below is an example use of class properties. The Tank class has a computed property named bonusDamage that is used to increase the damage for all tanks when upgrading. When an upgrade is complete all we need to do is callTank.upgrade() and all Tank instances will have more damage.

class Tank {
    class var bonusDamage: Double {
        return Double(Upgrade.level) * 2.5
    }

    let baseDamage = 10.0

    var damage: Double {
        return self.baseDamage + Tank.bonusDamage
    }

    class func upgrade() {
        Upgrade.level += 1
    }

    struct Upgrade {
        static var level = 0
    }
}

var tank = Tank()

println(tank.damage)
// 10.0

Tank.upgrade()

println(tank.damage)
// 12.5

Tank.upgrade()

println(tank.damage)
// 15.0

Inheritance

A class can inherit methods, properties, and other characteristics from another class. When one class inherits from another, the inheriting class is known as a subclass, and the class it inherits from is known as its superclass. Inheritance is a fundamental behavior that differentiates classes from other types in Swift.

A simple example of inheritance:

class AClass {
    func doSomething() {
        println("Hello from AClass")
    }
}

class Subclass: AClass  {
}

let base_object = AClass()
base_object.doSomething()
//> Hello from AClass


let enhanced_object = Subclass()
enhanced_object.doSomething()
// > Hello from AClass

Overriding

You can override methods in order to provide custom behaviour. To override a method write the override keyword before the method declaration:

class AClass {
    func doSomething() {
        println("Hello from AClass")
    }
}

class Subclass: AClass  {
    override func doSomething() {
        println("Hello from Subclass")
    }
}

let base_object = AClass()
base_object.doSomething()
//> Hello from AClass


let enhanced_object = Subclass()
enhanced_object.doSomething()
//> Hello from Subclass

You can use the super keyword to call any method from the superclass.

...

class Subclass: AClass  {
    override func doSomething() {
        super.doSomething()

        println("Hello from Subclass")
    }
}

let enhanced_object = Subclass()
enhanced_object.doSomething()
//> Hello from AClass
//> Hello from Subclass

Base class

A class that does not inherit from another class is called a base class, for example:

class User {
    var name: String!
    var age: Int!

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

The iOS and Mac OS classes usually inherit from NSObject, either directly or indirectly. If you have a mixt codebase I would encourage you to subclass NSObject when creating a new class:

Swift classes that are subclasses of NSObject:

• are Objective-C classes themselves
• use objc_msgSend() for calls to (most of) their methods
• provide Objective-C runtime metadata for (most of) their method implementations

Swift classes that are not subclasses of NSObject:

• are Objective-C classes, but implement only a handful of methods for NSObject compatibility
• do not use objc_msgSend() for calls to their methods (by default)
• do not provide Objective-C runtime metadata for their method implementations (by default)

Subclassing NSObject in Swift gets you Objective-C runtime flexibility but also Objective-C performance. Avoiding NSObject can improve performance if you don’t need Objective-C’s flexibility.

from stackoverflow Swift native base class or NSObject

Protocols

Protocols are declared in a similar way to classes.

protocol MyFirstProtocol {
    // I do nothing
}

Protocols describe methods, properties and other requirements that are needed for a specific task. For example theUITableViewDelegate protocol lists all the methods that can be used to react to user events and configure a table view.

Note: you can mark a method as optional using the @optional keyword. All of the methods fromUITableViewDelegate are optional. When you do not use the @optional keyword that method is required. The swift compiler will throw an error if a class conforms to a protocol and does not implement the required methods.

A class can conform to a protocol by placing its name after the type’s name separated by a colon, as part of their definition. Multiple protocols can be listed, and are separated by commas:

class AnotherSwiftClass: MyFirstProtocol, AnotherProtocol {
    ...
}

If the class inherits from another one, make sure to put the superclass name before the protocol list.

class AnotherSwiftClass: AClass, MyFirstProtocol, AnotherProtocol {
    ...
}

Note: Protocols use the same syntax as normal methods, but are not allowed to specify default values for method parameters.

Delegate Pattern

One of the most overused design pattern in iOS is delegation. A class can delegate a part of it’s responsibilities to an instance of another class. This design pattern is implemented by defining a protocol that encapsulates the delegated responsibilities, such that a conforming type (known as a delegate) is guaranteed to provide the functionality that has been delegated.

Here is an example, the Player class delegates the shooting logic to the weapon:

protocol Targetable {
    var life: Int { get set }
    func takeDamage(damage: Int)
}

protocol Shootable {
    func shoot(target: Targetable)
}

class Pistol: Shootable {
    func shoot(target: Targetable) {
        target.takeDamage(1)
    }
}

class Shotgun: Shootable {
    func shoot(target: Targetable) {
        target.takeDamage(5)
    }
}

class Enemy: Targetable {
    var life: Int = 10

    func takeDamage(damage: Int) {
        life -= damage
        println("enemy lost \(damage) hit points")

        if life <= 0 {
            println("enemy is dead now")
        }
    }
}

class Player {
    var weapon: Shootable!

    init(weapon: Shootable) {
        self.weapon = weapon
    }

    func shoot(target: Targetable) {
        weapon.shoot(target)
    }
}

var terminator = Player(weapon: Pistol())

var enemy = Enemy()

terminator.shoot(enemy)
//> enemy lost 1 hit points
terminator.shoot(enemy)
//> enemy lost 1 hit points
terminator.shoot(enemy)
//> enemy lost 1 hit points
terminator.shoot(enemy)
//> enemy lost 1 hit points
terminator.shoot(enemy)
//> enemy lost 1 hit points

// changing weapon because the pistol is inefficient
terminator.weapon = Shotgun()

terminator.shoot(enemy)
//> enemy lost 5 hit points
//> enemy is dead now

Polymorphism

Polymorphism means “having multiple forms”. Objects of different classes can be used interchangeably if they have a common superclass.

Here is a simple example in which multiple instances can be used as a GraphicObject.

class GraphicObject {

    func draw() {
        println("does nothing")
    }
}

class SpaceShip: GraphicObject {
}

class EmpireSpaceShip: SpaceShip {
    override func draw() {
        println("draws an empire space ship")
    }
}

class RebellionSpaceShip: SpaceShip {
    override func draw() {
        println("draws a rebellion space ship")
    }
}

class DeathStar: GraphicObject {
    override func draw() {
        println("draws the Death Star")
    }
}

var spaceShips = [EmpireSpaceShip(), RebellionSpaceShip(), DeathStar()]

for spaceShip in spaceShips {
    spaceShip.draw()
}

This program will output:

draws an empire space ship
draws a rebellion space ship
draws the Death Star

Singleton Pattern

Sometimes it’s important to have only one instance for a class. For example, in a system there should be only one window manager (or only a file system, or one motion manager on an iPhone). To achieve this effect in swift we are going to expose the singleton instance using a class property.

class Singleton {
    struct Static {
        static let instance = Singleton()
    }

    class var sharedInstance: Singleton {
        return Static.instance
    }
}

Singleton.sharedInstance

or:

import Foundation

class DispatchSingleton {
    struct Static {
        static var onceToken : dispatch_once_t = 0
        static var instance : DispatchSingleton? = nil
    }

    class var sharedInstance : DispatchSingleton {
        dispatch_once(&Static.onceToken) {
            Static.instance = DispatchSingleton()
        }
        return Static.instance!
    }
}

DispatchSingleton.sharedInstance

Model View Controller

The best explanation I found was from Apple:

The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries. The collection of objects of a certain MVC type in an application is sometimes referred to as a layer—for example, model layer.

MVC is central to a good design for a Cocoa application. The benefits of adopting this pattern are numerous. Many objects in these applications tend to be more reusable, and their interfaces tend to be better defined. Applications having an MVC design are also more easily extensible than other applications. Moreover, many Cocoa technologies and architectures are based on MVC and require that your custom objects play one of the MVC roles.

Model Objects

Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data—it should not be concerned with user-interface and presentation issues.

Communication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.

View Objects

A view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application’s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.

Because you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.

Communication: View objects learn about changes in model data through the application’s controller objects and communicate user-initiated changes—for example, text entered in a text field—through controller objects to an application’s model objects.

Controller Objects

A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.

Communication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.

Challenges

• create a Shape base class and derive from it Circle, Square and Rectangle. Shape should have two methods area() -> Float and perimeter() -> Float that both return 0. Implement the methods and add the necessary properties on Circle, Square and Rectangle.
• create the same classes from the first exercise, but this time make Shape a protocol
• create a custom initializer for Circle, Square and Rectangle and create two instance of each one.
• add the instance created in the exercise above into an array shapes and use polymorphism to find out the total area and perimeter of the shapes
• solve the exercise above using map and reduce
• add a armor property to the Targetable protocol and reduce the damage taken by the enemy. Obs: you will need to change the life property type to Float in order to do this.

Future reading

• for a more in depth look at design pattern read Design Patterns: Elements of Reusable Object-Oriented Software

References

• Why a Duck? – An Introduction to Polymorphism and Design Patterns
• Apple’s Cocoa Core Competencies Model-View-Controller