Protocol oriented programming_talk_ppt

Protocol Oriented Programming
Jayant Jaiswal, iOS Engineer, UrbanClap
#SwiftMeetup

What is it, in the first place ?

What is it, in the first place ?
Protocol Oriented Programming is a paradigm based around
the concept of Protocol Extensions.

Design a View Controller
Configurable Navigation Bar
Animation like show and hide loader
Loading from xib

A common approach
Design a base View Controller that gets inherited to all
those controllers that share the similarity.

A common approach
Design a base View Controller that gets inherited to all
those controllers that share the similarity.
This approach works but has
some drawbacks

Drawbacks
Reusability, if same piece of code is required somewhere else

Drawbacks
Hard to navigate between classes and fix bugs, due to nested code

Drawbacks
Inherit unneeded properties and methods, making the object become bloated

Drawbacks
Inherit unneeded properties and methods, making the object become bloated
It is said, OOP is just a
modularized way of writing
spaghetti code

UIKit Framework in OOP
Would you ever like to work with the above code base?

Protocol Oriented Design to rescue

Separated out functionalities making them reusable

Flat Structured, non-nested code

Easier to debug and fix bugs

Works for both reference and value types - classes, enums and structs

Works for both reference and value types - classes, enums and structs
Let’s see them in action

Our Agenda Moving Ahead
What protocol Extensions are ?
How to think the Protocol Extension Way ?
How we can convert Object Oriented Design to its equivalent
Protocol Oriented with a cleaner design and Reusability?
Homogeneous and Heterogeneous Containers
Constraining Protocol Extensions with types
Protocol Associated Types(PATs)
Type Erasures

Add a functionality over Integers to convert them to string

A common approach

A common approach
Do the same for Float

Design a View Controller
Should be able to show a pop up
Should be able to configure right bar button item

Redesigning using Protocol Oriented Programming

Using the Newly designed Protocols

A simple example of how the Swift Team has used
Protocol Extensions
public protocol Sequence {
//Some come
public func map<T>(_ transform: (Self.Element) throws -> T ) rethrows -> [T]
}
extension Sequence {
public func map<T>(_ transform: (Self.Element) throws -> T ) rethrows -> [T] {
//Implementation by Swift Team
}
}
extension Array: Sequence { }
extension ArraySlice: Sequence { }
extension ReversedCollection: Sequence { }

Task 1
Calling the above method would result in 7 and 123a respectively

Problem:
Both the situations
are possible

Heterogenous Containers
Problem:
Both the situations
are possible

Heterogenous Containers
Constraint
Each element conforms to Summable

Advantages of Homogeneous over Heterogeneous
Containers

Containers
The tedious type check has been eliminated that we had to do in the
heterogenous case.

Containers
The tedious type check has been eliminated that we had to do in the
heterogenous case.
Eliminated the need to do dynamic time type checking and replaced it with safer
compile time type assertion.

Constraining Protocol Extensions With Types

public protocol ReusableView : class {
static var cellReuseIdentifier : String { get }
}

}
extension ReusableView {
public static var cellReuseIdentifier : String {
return String(describing: self)
}
}

}
extension ReusableView {
}
}
Would the above extension really make any sense if we conform a String, Int
or any other type to this protocol apart from UIView ?

}
extension ReusableView where Self : UIView {
}
}

How Swift Team used this trick in the Swift Standard library ?

extension CollectionType {
public func index(of element: Generator.Element ) -> Index? {
for i in self.indices {
if self[ i ] == element {
return i
}
}
return nil
}
}

return i
}
}
return nil
}
}
Can elements of arbitrary collections be compared with == ?

return i
}
}
return nil
}
}
binary operator ‘==‘ cannot be applied to
two Generator.Element operands

extension CollectionType where Generator.Element : Equatable {
public func index(of element: Generator.Element ) -> Int? {
return i
}
}
return nil
}
}

protocol BasePower {
init( )
}
class Pokemon <Power : BasePower> {
func attack( ) -> Power {
return Power( )
}
}
Protocol Associated Types

protocol BasePower {
init( )
}
class Pokemon <Power : BasePower> {
return Power( )
}
}
Power Types
struct WaterPower : BasePower { }
struct FirePower : BasePower { }
struct LighteningPower : BasePower { }

class Pikachu : Pokemon<LighteningPower> { }
class Squirtle : Pokemon<WaterPower> { }
class Charizard : Pokemon<FirePower> { }

let pikachu = Pikachu( )
pikachu.attack( )
let squirtle = Squirtle( )
squirtle.attack( )
let charizard = Charizard( )
charizard.attack( )

let pikachu = Pikachu( )
pikachu.attack( )
let squirtle = Squirtle( )
squirtle.attack( )
let charizard = Charizard( )
charizard.attack( )
Problem:
Subclassing. It starts out with great
intentions, but eventually things get
a lot messier as exceptions arise.

protocol Pokemon {
associatedtype Power : BasePower
func attack( ) -> Power
}
extension Pokemon {
return Power( )
}
}

struct Pikachu : Pokemon {
typealias Power = LighteningPower
}
struct Squirtle : Pokemon {
// Here WaterPower is inferred as the associatedtype
func attack( ) -> WaterPower {
// custom attack logic
return WaterPower( )
}
}

let pokemon: Pokemon
pokemon.attack( )
Type Erasures

pokemon.attack( )
Protocol Pokemon can only be used as a generic constraint
because it has self or associated type requirements
Type Erasures

pokemon.attack( )
Protocol Pokemon can only be used as a generic constraint
because it has self or associated type requirements
Type Erasures
Problem:
Pokemon is an abstract type, so we cannot instantiate it directly.

Type Erasures
class AnyPokemon <Power>: Pokemon {
private let _attack: ( ) -> Power
required init<U: Pokemon>(_ pokemon: Pokemon)
where U.Power == Power {
_attack = pokemon.attack
}
_attack( )
}
}

Type Erasures
let p1 = AnyPokemon(Pikachu)
}
_attack( )
}
}

Type Erasures
let p2: AnyPokemon<FirePower>
p2 = AnyPokemon(Charizard)
}
_attack( )
}
}

Type Erasures
AnyPokemon<LighteningPower>
}
_attack( )
}
}

Type Erasures
AnyPokemon<LighteningPower>
AnyPokemon<FirePower>
}
_attack( )
}
}

Lets summarise…
How OOP can make things messier in the long run
How Protocol Oriented Design can overcome all the shortcomings
of OOPs
What are protocol extensions and how we can go about using them.
How we can go about converting from OOP to POP
Homogenous and Heterogenous Containers
Constraining extensions with types
Protocol Associated Types(PATs)
Type Erasures

Protocol oriented programming_talk_ppt

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Protocol oriented programming_talk_ppt

Similar to Protocol oriented programming_talk_ppt (20)

Recently uploaded

Recently uploaded (9)

Protocol oriented programming_talk_ppt