The document discusses protocol-oriented programming in Swift. It begins by comparing protocols in Swift vs Objective-C, noting key differences like protocol inheritance, extensions, default implementations, and associated types in Swift. It then defines protocol-oriented programming as separating public interfaces from implementations using protocols that components communicate through. Examples are provided of using protocols for data types, dependency injection, testing, and real-world UIKit views. Protocol-oriented programming is said to improve reusability, extensibility, and maintainability over inheritance-based approaches.

1. Protocol-Oriented
Programming in Swift
Oleksandr Stepanov

2. Oleksandr Stepanov
iOS developer @ AKQA Inc.

3. We are hiring!

4. Agenda

5. Agenda
• Protocols in Swift vs Objective-C

6. Agenda
• Protocols in Swift vs Objective-C
• Protocol-oriented programming
‣ What is that?
‣ Why to use it?
‣ How to use it?

7. Agenda
• Protocols in Swift vs Objective-C
• Protocol-oriented programming
‣ What is that?
‣ Why to use it?
‣ How to use it?
• Examples

8. Protocols

9. protocol someProtocol {
}

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

11. protocol someProtocol {
var someInt: Int { get }
var someString: String? { get set }
func doSomething(inputA: Int) -> String?
}

12. protocol someProtocol {
associatedtype TypeA;
var someInt: Int { get }
var someString: String? { get set }
func doSomething(inputA: Int) -> String?
func doSomethingWithTypeA(typeA: TypeA)
}

13. protocol someProtocol {
associatedtype TypeA;
var someInt: Int { get }
var someString: String? { get set }
func doSomething(inputA: Int) -> String?
func doSomethingWithTypeA(typeA: TypeA)
}
protocol successorProtocol: someProtocol {
}

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

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

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

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

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

19. Protocol-oriented
programming
🤔

20. Protocol-oriented
programming
What is this?
🤔

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

22. WWDC 2015 - Session 408
Protocol-Oriented Programming in Swift
“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/

23. Cars project 🚗

24. Implementation
Inheritance approach

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

26. class Car {
let wheels = 4
func make() {
print("🚗 is built")
}
}
class CarFactory {
var model: Car?
func makeACar() {
model?.make()
}
}

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

28. Let’s make 🏎

29. …
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

30. Let’s make 🏍

31. Implementation
Inheritance problems

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

33. Inheritance hierarchies
Hard to extend
class Car {
let wheels = 4
func make() {
print("🚗 is built")
}
}
class Sedan: Car {}

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

35. Protocol-oriented
programming approach

37. ✦ Separation of public interface
from the implementation

38. ✦ Separation of public interface
from the implementation
✦ Software defined in components
that talk to each other using
interfaces

39. ✦ Separation of public interface
from the implementation
✦ Software defined in components
that talk to each other using
interfaces
✦ May be used in conjunction with
classes, structs and enums.

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

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

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

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

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

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

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

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

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

50. ✦ Reusability

51. ✦ Reusability
✦ Extensibility

52. ✦ Reusability
✦ Extensibility
✦ Black-boxed

53. ✦ Reusability
✦ Extensibility
✦ Black-boxed
MORE MAINTAINABLE

54. Patterns
where it can be useful

56. ✦ Data types
• Abstraction
• Mock objects for test

57. ✦ Data types
• Abstraction
• Mock objects for test
✦ Dependency injection

58. ✦ Data types
• Abstraction
• Mock objects for test
✦ Dependency injection
✦ Detached architecture
• MVVM

59. ✦ Data types
• Abstraction
• Mock objects for test
✦ Dependency injection
✦ Detached architecture
• MVVM
✦ Testing
• Unit
• A/B testing interfaces

60. Real life example

61. Real life example
UIKit

62. Table view cell

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

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

65. import UIKit
struct Event {
let icon: UIImage?
let title: String
let date: Date
}
class EventTableViewCell: UITableViewCell {
@IBOutlet var iconView: UIImageView!
@IBOutlet var titleLabel: UILabel!
@IBOutlet var dateLabel: UILabel!
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}

66. Collection view cell

67. …
class EventTableViewCell: UITableViewCell {
…
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}
class EventCollectionViewCell: UICollectionViewCell {
…
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}

68. Header view

69. …
class EventTableViewCell: UITableViewCell {
…
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}
class EventCollectionViewCell: UICollectionViewCell {
…
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}
class EventHeaderView: UIView {
…
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
} }

70. Maintenance

71. Maintenance
😢

73. POP approach

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

75. protocol EventViewProtocol {
var iconView: UIImageView! { get set }
var titleLabel: UILabel! { get set }
var dateLabel: UILabel! { get set }
func set(event: Event)
}
extension EventViewProtocol {
func set(event: Event) {
iconView.image = event.icon
titleLabel.text = event.title
dateLabel.text = event.date.description
}
}

76. …
class EventTableViewCell: UITableViewCell {
@IBOutlet var iconView: UIImageView!
@IBOutlet var titleLabel: UILabel!
@IBOutlet var dateLabel: UILabel!
}
extension EventTableViewCell: EventViewProtocol
{}

77. Test it!
🔨

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

79. …
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)

80. …
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 )

82. ✦ No code duplication -> better
maintainable

83. ✦ No code duplication -> better
maintainable
✦ Better testable

84. ✦ No code duplication -> better
maintainable
✦ Better testable
PROFIT!

85. One more sample
POP + Enums

86. One more sample
POP + Enums
NSNotification

88. -Literal string names

89. -Literal string names
-Potential for mismatched strings

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

92. -Slightly better …

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

94. }

95. }

96. }

97. How to enhance it with POP ?
}

107. ❌

111. ✦ No mismatched strings

112. ✦ No mismatched strings
✦Simpler to read and maintain

113. ✦ No mismatched strings
✦Simpler to read and maintain
✦ Notification handlers may be
classes, structs and enums

114. ✦ No mismatched strings
✦Simpler to read and maintain
✦ Notification handlers may be
classes, structs and enums
✦ … the same for notification type

116. reusability

117. reusability
extensibility

118. understandability
reusability
extensibility

119. maintainability
understandability
reusability
extensibility

120. maintainability
understandability
testability
reusability
extensibility

121. POP
maintainability
understandability
testability
reusability
extensibility

123. it’s not a

124. it’s not a

125. treat it carefully

126. Thank you!

127. Q&A