Protocol-Oriented Programming in Swift

Protocol-Oriented
Programming in Swift
Oleksandr Stepanov

Oleksandr Stepanov
iOS developer @ AKQA Inc.

Agenda
• Protocols in Swift vs Objective-C

Agenda
• Protocol-oriented programming
‣ What is that?
‣ Why to use it?
‣ How to use it?

Agenda
• Protocol-oriented programming
‣ What is that?
‣ Why to use it?
‣ How to use it?
• Examples

protocol someProtocol {
var someInt: Int { get }
var someString: String? { get set }
}

func doSomething(inputA: Int) -> String?
}

associatedtype TypeA;
func doSomethingWithTypeA(typeA: TypeA)
}

associatedtype TypeA;
func doSomethingWithTypeA(typeA: TypeA)
}
protocol successorProtocol: someProtocol {
}

…
extension somethingProtocol {
func doSomethingDifferent() {
print("Oh man, that is different")
}
func doSomethingWithTypeA(typeA: TypeA) {
print("typeA: (typeA)")
}
}

Protocols
Swift Objective-C
Protocol Inheritance ✅ ❌
Protocol extensions ✅ ❌
Default implementation ✅ ❌
Associated Types (aka Generics) ✅ ❌
Available in structures and
enums as well ✅ ❌

Swift Objective-C
Optional methods ❌ ✅
Protocols

import Foundation
@objc protocol optionalProtocol {
@objc optional func someOptionalMethod()
@objc optional var someOptionalInt: Int { get
set }
}

Swift Objective-C
Optional methods ✅
(@objc)
✅
Protocols

Protocol-oriented
programming
🤔

Protocol-oriented
programming
What is this?
🤔

WWDC 2015 - Session 408
Protocol-Oriented Programming in Swift
“Swift is a protocol-oriented programming language.”
Dave Abrahams

WWDC 2015 - Session 408
“Swift is a protocol-oriented programming language.”
Dave Abrahams
https://developer.apple.com/videos/play/wwdc2015/408/
https://developer.apple.com/videos/play/wwdc2016/419/

Implementation
Inheritance approach

class Car {
let wheels = 4
func make() {
print("🚗 is built")
}
}

class Car {
let wheels = 4
func make() {
}
}
class CarFactory {
var model: Car?
func makeACar() {
model?.make()
}
}

…
class Sedan: Car {}
let sedan = Sedan()
let carFactory = CarFactory()
carFactory.model = sedan
carFactory.makeACar() // prints “🚗 is built”

…
class Bolide: Car {
override func make() {
print("🏎 is built")
}
}
let bolide = Bolide()
let bolideFactory = CarFactory()
bolideFactory.model = bolide
bolideFactory.makeACar() // prints "🏎 is built"
Page 1 of 1

Implementation
Inheritance problems

class CarFactory {
var model: Car?
func makeACar() {
model?.make()
}
}
Tight coupling
Hard to maintain

Inheritance hierarchies
Hard to extend
class Car {
let wheels = 4
func make() {
}
}
class Sedan: Car {}

Implementation is a
white-box
… even using proper encapsulation
class Car {
let wheels = 4
func make() {
}
}
class Sedan: Car {}

Protocol-oriented
programming approach

✦ Separation of public interface
from the implementation

✦ Software defined in components
that talk to each other using
interfaces

✦ Software defined in components
that talk to each other using
interfaces
✦ May be used in conjunction with
classes, structs and enums.

protocol Vehicle {
func make()
}
protocol WheelsVehicle {
var wheels: Int { get }
}

…
protocol FourWheelsVehicle: WheelsVehicle {}
extension FourWheelsVehicle {
var wheels: Int {
get {
return 4
}
}
}

…
struct Car: Vehicle, FourWheelsVehicle {
func make() {
print("🚗 is built") }
}
}
struct Bolide: Vehicle, FourWheelsVehicle {
func make() {
print("🏎 is built")
}
}

…
protocol TwoWheelsVehicle: WheelsVehicle {}
extension TwoWheelsVehicle {
var wheels: Int { get { return 2 } }
}
struct MotorBike: Vehicle, TwoWheelsVehicle {
func make() {
print("🏍 is built") }
}
}

…
protocol VehicleFactory {
var model: Vehicle? { get set }
func makeACar()
}
extension VehicleFactory {
func makeACar() {
model?.make()
}
}

…
extension VehicleFactory {
func repairACar() {
// ...
}
}

…
class CarFactory: VehicleFactory {
var model: Vehicle?
}
let bolide = Bolide()
let carFactory = CarFactory()
carFactory.model = bolide
carFactory.makeACar() // prints "🏎 is built"

✦ Reusability
✦ Extensibility

✦ Reusability
✦ Extensibility
✦ Black-boxed

✦ Reusability
✦ Extensibility
✦ Black-boxed
MORE MAINTAINABLE

Patterns
where it can be useful

✦ Data types
• Abstraction
• Mock objects for test

✦ Data types
• Abstraction
✦ Dependency injection

✦ Data types
• Abstraction
✦ Detached architecture
• MVVM

✦ Data types
• Abstraction
✦ Detached architecture
• MVVM
✦ Testing
• Unit
• A/B testing interfaces

import UIKit
struct Event {
}
class EventTableViewCell: UITableViewCell {
}

import UIKit
struct Event {
let icon: UIImage?
let title: String
let date: Date
}
@IBOutlet var iconView: UIImageView!
@IBOutlet var titleLabel: UILabel!
@IBOutlet var dateLabel: UILabel!
}

import UIKit
struct Event {
let icon: UIImage?
let title: String
let date: Date
}
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}

…
…
}
}
class EventCollectionViewCell: UICollectionViewCell {
…
}
}

…
…
}
}
class EventCollectionViewCell: UICollectionViewCell {
…
}
}
class EventHeaderView: UIView {
…
} }

protocol EventViewProtocol {
var iconView: UIImageView! { get set }
var titleLabel: UILabel! { get set }
var dateLabel: UILabel! { get set }
func set(event: Event)
}

protocol EventViewProtocol {
var iconView: UIImageView! { get set }
var titleLabel: UILabel! { get set }
var dateLabel: UILabel! { get set }
func set(event: Event)
}
extension EventViewProtocol {
}
}

…
}
extension EventTableViewCell: EventViewProtocol
{}

…
import XCTest
class TestView {
var iconView: UIImageView! = UIImageView()
var titleLabel: UILabel! = UILabel()
var dateLabel: UILabel! = UILabel()
}
extension TestView: EventViewProtocol {}

…
let eventDate = Date.init()
let event = Event.init(icon: UIImage.init(named: “testEventIcon”)
title: "event title",
date: eventDate)
let testView = TestView()
testView.set(event: event)

…
let eventDate = Date.init()
let event = Event.init(icon: UIImage.init(named: “testEventIcon”)
title: "event title",
date: eventDate)
let testView = TestView()
testView.set(event: event)
XCTAssertEqual ( testView.iconView.image,
UIImage.init(named:”testEventIcon”) )
XCTAssertEqual ( testView.titleLabel.text,
"event title” )
XCTAssertEqual ( testView.dateLabel.text,
eventDate.description )

✦ No code duplication -> better
maintainable

maintainable
✦ Better testable

maintainable
✦ Better testable
PROFIT!

One more sample
POP + Enums
NSNotification

-Literal string names
-Potential for mismatched strings

-Literal string names
-Potential for mismatched strings
-There must be a better approach

-Slightly better …
-… but can we do even better?

How to enhance it with POP ?
}

✦ No mismatched strings
✦Simpler to read and maintain

✦ Notification handlers may be
classes, structs and enums

✦ Notification handlers may be
classes, structs and enums
✦ … the same for notification type

understandability
reusability
extensibility

maintainability
understandability
reusability
extensibility

maintainability
understandability
testability
reusability
extensibility

POP
maintainability
understandability
testability
reusability
extensibility

Protocol-Oriented Programming in Swift

Recommended

More Related Content

What's hot (20)

Similar to Protocol-Oriented Programming in Swift (20)

Recently uploaded (20)

Protocol-Oriented Programming in Swift