Protocol Oriented Programming in
下列内容是摘录Reference的文章而生成的读书笔记。
Protocol v.s. Base Class
- Multiple Inheritance. You mostly start with single class inheritance but then you realize that you need some more functionality in your class from some different class. This makes you lean towards multiple inheritance which is not supported by most programming languages and leads to undesired complexity.
- Protocols can be adopted by classes, structs and enums. Base classes and inheritance are restricted to class types.
- As classes are reference types passing them around in functions can cause unexpected behavior especially if you are working in a multi threaded environment.
- Unit Test. Due to tight coupling of classes with one another it becomes difficult to write unit tests for a single class.
Protocol v.s. Simple Category/Extension
Protocol makes codes more readable and organizable. And it also provides more access control, since functions in category/extension are accessable for class instances.
Let’s say your product manager comes over and says, “We want a view that when you click a button, it starts shaking.” This is a very common animation with password fields for example – when the user enters the wrong password, it might shake. So we can use the UI extension below to add shake to all UIViews.
extension UIView {
func shake() {
let animation = CABasicAnimation(keyPath: "position")
animation.duration = 0.05
animation.repeatCount = 5
animation.autoreverses = true
animation.fromValue = NSValue(CGPoint: CGPointMake(self.center.x - 4.0, self.center.y))
animation.toValue = NSValue(CGPoint: CGPointMake(self.center.x + 4.0, self.center.y))
layer.addAnimation(animation, forKey: "position")
}
}
If you have done this much for categories and extending UI views, you might have had better experience. It becomes this Frankenstein garbage place where you start adding a shake and then someone comes and says, “We want a dimmable view”. Then you add a dim function and then there is some other random function. It becomes this long, unreadable, hard-to-find garbage file with all these random things that UI view could do, but only maybe one or two things need to do that.
It is not clear what the intention is. How can we change this?
This is a talk about protocol-oriented programming, so we are going to use protocols. Let’s create a Shakeable protocol:
protocol Shakeable { }
extension Shakeable where Self: UIView {
func shake() {
// implementation code
}
}
With protocol extensions, you can constrain them to specific classes. In this case, I can take out my shake function, and, with the category, I can say that only things that conform to this protocol, only UI views, will have this function.
Similarly, we could create the following protocol.
protocol ReusableView: class {}
extension ReusableView where Self: UIView {
static var reuseIdentifier: String {
return String(self)
}
}
protocol NibLoadableView: class { }
extension NibLoadableView where Self: UIView {
static var nibName: String {
return String(self)
}
}
References
How Protocol Oriented Programming in Swift saved my day?
Beyond Crusty: Real-World Protocols
Raywenderlich: Introducing Protocol-Oriented Programming in Swift 3
