Swift Protocol-oriented programming

I. Benefits of using classes 1. Encapsulation 2. Abstract 3. Use namespaces to avoid conflicts 4. Statement 5. Scalability
In Swift, the first three points are completely achievable using structs and enumerations.
Second, in the past object-oriented programming, only classes can provide 1 of the inheritance hierarchy of Classes 2. Class because the method variable can be overloaded by the customization and reusability of
In swift, customizable structures can also be implemented.
Third, the use of class costs 1. Implicit sharing of reference types (implicit sharing) to do this, you sometimes need to call copy to give each variable (mutable) its own value, and it will reduce the efficiency of the system, may lead to deadlock, make the code more complex, can also cause a variety of bugs.
The CollectionType of absolute sharing in the past will not arise in Swift, because collectiontype in Swift is a value type rather than a reference type and they are not shared.
2. You need to inherit everything from the parent. It's too bloated, all that might be relevant is lost in a brain, and you have to decide your parent in the first, not the late.
If the parent class has a variable that stores the type, you have no choice but to accept them all. And to initialize them, be careful not to break the constants of the parent class.
You need to choose whether and how to overload the parent-class method in a workable way.
3. The abstraction of a class causes the loss of relational information between types (Lost type relationship) When you don't understand any of the information, you must also put some code in the original parent class in the overloaded method.
You need to use as!. The type of abstraction is further clarified.
We need a better abstraction. 1. Support value types (including classes) 2. Support for static type relationships (static type relationship) and dynamic distribution 4. Support for traceable model design 5. No data 6, no initialization burden 7. Identify what the recipient will achieve (contrast to the ambiguity of the class method overload)
V. Swift is a protocol-oriented (protocol-oriented) programming language
Everything begins with the agreement 1. Avoid writing unnecessary methods to implement code 2. Overload 3 is no longer required. Use Self in the Protocol method definition to resolve Type relationship loss (Lost type relationship)
Protocol Ordered {
func precedes (Other: Self )-> Bool }
4. Conversion of heterogeneous declarations into homogeneous
When ordered is class:
func BinarySearch (sortedkeys: [ Ordered ], Forkey K: Ordered )-> Int {
var lo = 0
var hi = Sortedkeys. Count
while Hi > Lo {
Let mid = lo + (hi-lo)/ 2
if Sortedkeys[mid].precedes (k) {
Lo = mid + 1
} Else {
Hi = mid
}
}
return Lo }
When ordered is protocol:
func binarysearch<t:ordered> (sortedkeys: [ T ], Forkey K: T )-> Int {     var lo = 0
var hi = Sortedkeys. Count
while Hi > Lo {
Let mid = lo + (hi-lo)/ 2
if Sortedkeys[mid]. precedes (k) {
Lo = mid + 1
} Else {
Hi = mid
}
}
return Lo }
Vii. If you use self in Protocol, the difference between Protocol and class will be greater 1. Use generics instead of type 2. A way of thinking that is homogeneous rather than heterogeneous 3. Communication between type instances no longer means communication between two types 4. Adopt more efficient static distribution mode
VIII. Protocol Development Grammar See the Swift 2.0 syntax update four days ago (ii)




Renderer is a protocol,testrenderer that satisfies the Renderer structure. The first diagram expands the renderer and adds two methods, one for the circleat required in the original protocol and for the newly added rectangleat. The second diagram expands the testrenderer of the structure body, adding two identical methods.
If you define r in the way shown in Figure II, Circleat will call circleat in extension textrenderer, and Rectangleat will invoke extension in render rectangleat.
In this definition, priority is the protocol extension method, which is not required in the original protocol > type extension method > The Protocol extension method required in the original protocol.
Nine, more Protocol Extension Tricks due to the level of limited temporarily do not translate
Ten, when we should use Class 1. When comparisons and replication of instances are meaningless (for example: Window) 2. The life cycle of an instance depends on the time of the external impact (for example, a temporary file) 3. An instance can only be written to affect the external state (for example: Cgcontext) 4. And do not confront the Object-oriented system API
Xi. Summary Protocol > superclasses Extension Protocol is amazing.
English original video See WWDC session 408 https://developer.apple.com/videos/wwdc/2015/?id=408