Protocol-oriented programming in Swift

Introduction to Protocol-oriented Programming in Swift and why to embrace it to make plug-compatible components in our application designs.

Transcript

1. PROTOCOL-ORIENTED PROGRAMMING IN SWIFT
3. Buy and sell quickly and locally @ahernandezlopez
4. HOW MY APP COMPONENTS TALK TO EACH OTHER?
5. DIGITAL BAKERY
6. I WANT TO COOK DIGITAL CAKES IN A DIGITAL OVEN A hipster product owner
7. AN IMPLEMENTATION INHERITANCE APPROACH
8. ▸Polymorphism ▸Implicit reuse of method implementations ▸We can hide implementation details to clients
9. class Cake { func cook() { print(" is cooked!") } } class CheeseCake: Cake {}
10. class Oven { var cake: Cake? func turnOn() { cake?.cook() } }
11. let cheeseCake = CheeseCake() let oven = Oven() oven.cake = cheeseCake oven.turnOn() // Output: “ is cooked!”
12. WE HAVE OBSERVED THE METRICS, MOST OF OUR CLIENTS ARE VEGAN. LET’S GO WITH CARROT CAKES INSTEAD. That hipster product owner
13. class CarrotCake: Cake {} // ... let carrotCake = CarrotCake() let oven = Oven() oven.cake = carrotCake oven.turnOn() // Output: “ is cooked!”
14. WE NEED TO PIVOT, TO DISRUPT THE BAKERY WORLD. WE SHOULD OFFER PIZZA AS WELL. That hipster product owner...
15. IMPLEMENTATION INHERITANCE PROBLEMS
16. TIGHT COUPLING class Oven { var cake: Cake? func turnOn() { cake?.cook() } } HARD TO MAINTAIN
17. INHERITANCE HIERARCHIES class Cake { func cook() { print(" is cooked!") } } class CheeseCake: Cake {} HARD TO EXTEND
18. IMPLEMENTATION IS A WHITE-BOX class Cake { func cook() { print(" is cooked!") } } class CheeseCake: Cake {} HARD TO REUSE even using proper encapsulation
19. PROTOCOL-ORIENTED PROGRAMMING
20. ▸Separation of the public interface from the implementation ▸Software defined in components which talk to each other using interfaces ▸Not new, AKA interface-based programming
 Probably popularized with Java
21. ▸POP is at heart of Swift’s design public struct Array<Element> : CollectionType, MutableCollectionType, _DestructorSafeContainer //... public protocol CollectionType : Indexable, SequenceType { //... public protocol Indexable { //...
 public protocol SequenceType { //... extension SequenceType { //...
22. PROTOCOLS
23. ▸are shared boundaries across which information is passed ▸declare methods and properties that are required to be provided by its implementation/s ▸can be adopted by classes, structs and enums ▸can be inherited, one or multiple ▸protocol extensions ▸generics with associated types
24. protocol Cookable { func cook() } protocol Edible { func eat() } protocol IngredientType: Cookable, Edible { var calories: Int { get } } struct Ingredient: IngredientType { let calories: Int func cook() { print(“") } func eat() { print(“") } }
25. ▸from a design standpoint, an interface is a contract ▸when POP’ing we have plug-compatible objects (not tight to an implementation) ▸interfaces offer polymorphism independent of the inheritance hierarchy ▸reusability, maintainability, and extensibility
26. A PROTOCOL- ORIENTED APPROACH
27. protocol Cookable { func cook() } struct CarrotCake: Cookable { func cook() { print(" is cooked!") } } struct Pizza: Cookable { func cook() { print(" is cooked!") } } class Cake { func cook() print(" } } class CheeseCak REUSABILITY
28. class Cake { func cook() { print(" is cooked!") } } extension Cake: Cookable {} EXTENSIBILITY
29. protocol CookingMachine { var cookable: Cookable? { get set } func turnOn() } extension CookingMachine { func turnOn() { cookable?.cook() } } class Oven { var cake: Cak func turnOn() cake?.coo } } EXTENSIBILITY
30. //... extension CookingMachine { func turnOff() { //... } } EXTENSIBILITY
31. class Oven: CookingMachine { var cookable: Cookable? } BLACK-BOXED class Oven { var cake: Cak func turnOn() cake?.coo } } protocol Cookable { func cook() }
32. let carrotCake: Cookable = CarrotCake() let cookingMachine: CookingMachine = Oven() cookingMachine.cake = carrotCake cookingMachine.turnOn() // Output: “ is cooked!”
33. MORE MAINTANABLE
34. SOME PATTERNS WHERE IT CAN BE USEFUL?
35. ▸Modeling data types ▸Abstraction of your instances source ▸Clean way to build-up mock objects (tests) ▸Dependency injection (provider) ▸Subclassing == code smelly ▸Detached architecture (clean, MVVM…) ▸A/B testing interfacing
36. REAL-WORLD EXAMPLE
37. BUILD A FRAMEWORK THAT RETRIEVES A POSTAL ADDRESS GIVEN A GEOPOINT After POP’ing, our colleague PO
40. protocol GeoPointType { var latitude: Double { get } var longitude: Double { get } } struct GeoPoint: GeoPointType { let latitude: Double let longitude: Double } struct MockGeoPoint: GeoPointType { let latitude: Double = Double.random(-90...90) let longitude: Double = Double.random(-180...180) } /* let's assume we've a Double extension with the method:
 static func random(range: Range<Int>) -> Double */
41. /* CLPlacemark+PostalAddressType.swift */ extension CLPlacemark: PostalAddressType {} /* CLPlacemark.h */ public class CLPlacemark : NSObject, NSCopying, NSSecureCoding { //... public var locality: String? { get } public var country: String? { get } //... }
43. typealias RetrieveAddressCompletion = PostalAddressType? -> () protocol AddressDataSource { func retrieveAddress(geoPoint: GeoPoint, completion: RetrieveAddressCompletion?) } class MockAddressDataSource: AddressDataSource { var retrieveAddressResult: PostalAddressType? func retrieveAddress(geoPoint: GeoPoint, completion: RetrieveAddressCompletion?) { let delay = dispatch_time(DISPATCH_TIME_NOW, Int64(0.5 * Double(NSEC_PER_SEC))) dispatch_after(delay, dispatch_get_main_queue()) { [weak self] in completion?(self?.retrieveAddressResult) } } }
44. class AppleAddressDataSource: AddressDataSource { let geocoder: CLGeocoder init(geocoder: CLGeocoder) { self.geocoder = geocoder } func retrieveAddress(geoPoint: GeoPoint, completion: RetrieveAddressCompletion?) { let location = CLLocation(latitude: geoPoint.latitude, longitude: geoPoint.longitude) geocoder.reverseGeocodeLocation(location) { (placemarks, _) -> Void in let placemark = placemarks?.first completion?(placemark) } } }
45. class AddressRepository { private let addressDataSource: AddressDataSource init(addressDataSource: AddressDataSource) { self.addressDataSource = addressDataSource } func retrieveAddress(geoPoint: GeoPoint, completion: RetrieveAddressCompletion?) { addressDataSource.retrieveAddress(geoPoint, completion: completion) } }
46. ▸loosely coupled architecture with white- boxed implementation ▸maintainable: if we need to switch our data source implementation all our repo tests should remain GREEN ▸we can extend AddressRepository (but we’d do it POP’d ) ▸we can reuse this code in other projects
48. @ahernandezlopez THANKS! QUESTIONS? WE’RE HIRING albert@letgo.com (