프로토콜의 실용성

이것은 얼마나 잔인한지 보여줄 수 있는 예이다.

class PresentErrorViewController: UIViewController {
    var errorViewIsShowing: Bool = false
    func presentError(message: String = “Error!", withArrow shouldShowArrow: Bool = false, backgroundColor: UIColor = ColorSalmon, withSize size: CGSize = CGSizeZero, canDismissByTappingAnywhere canDismiss: Bool = true) {
        // ， 
    }
} 
// ， 100 class class 
EveryViewControllerInApp: PresentErrorViewController {}

프로젝트가 진행됨에 따라 일이 곧 명확해진다. 모든 UIVIew Controller가 이 error 논리를 필요로 하거나 이 클래스가 제공하는 모든 기능을 필요로 하는 것은 아니다.우리 팀의 어떤 사람이라도 이 슈퍼클래스에서 쉽게 뭔가를 고쳐서 전체 앱에 영향을 줄 수 있다.이것은 코드를 취약하게 만든다.코드를 다태적으로 만들었다.자류가 자신의 행동을 결정해야 하는데, 이곳의 슈퍼클래스는 결정을 도왔다.다음은 swift 2.0에서 우리가 어떻게 팝으로 이 코드를 더욱 잘 구축할 수 있는지:

protocol ErrorPopoverRenderer {
    func presentError(message: String, withArrow shouldShowArrow: Bool, backgroundColor: UIColor, withSize size: CGSize, canDismissByTappingAnywhere canDismiss: Bool)
} 
extension UIViewController: ErrorPopoverRenderer { // ErrorPopoverRenderer UIViewController presentError 
    func presentError(message: String, withArrow shouldShowArrow: Bool, backgroundColor: UIColor, withSize size: CGSize, canDismissByTappingAnywhere canDismiss: Bool) {
        // error 
    }
} 
class KrakenViewController: UIViewController, ErrorPopoverRenderer { //Drop the God class and make KrakenViewController conform to the new ErrorPopoverRenderer Protocol.
    func methodThatHasAnError() {
        //…
        // error， Kraken 。
        presentError(/*blah blah blah  */)
    }
}

봐라, 이곳에 멋진 일이 일어났다.우리는 하느님류의 존재를 없앴을 뿐만 아니라 코드를 더욱 모듈화하고 확장성을 강화했다.ErrorPoverRenderer 프로토콜을 만들면 이 프로토콜을 따르는class가 ErrorView를 보여줄 수 있습니다.뿐만 아니라, 우리의 Kraken View Controller class는present Error라는 함수를 반드시 실현해야 할 필요가 없습니다. 왜냐하면 우리는 UIVIew Controller를 확장하여 기본적으로 실현할 수 있기 때문입니다.
아이고, 잠깐만!이게 문제야!우리는 ErrorView를 구현할 때마다 매개 변수를 구현해야 합니다.프로토콜 함수 성명에서 파라미터에 기본값을 제공할 수 없기 때문에 이것은 좀 불쾌하다.
나는 아직도 이 파라미터들을 매우 좋아한다!더 나쁜 것은 코드를 더욱 모듈화된 특징을 가지게 하는 과정에서 우리는 복잡도를 도입했다.계속 하세요. swift 2.0에 새로 추가된 묘미로 얼마의 보상을 받을까요?

protocol ErrorPopoverRenderer {
    func presentError()
} 
extension ErrorPopoverRenderer where Self: UIViewController {
    func presentError() {
        // ， ErrorView 。
    }
}
class KrakenViewController: UIViewController, ErrorPopoverRenderer {
    func methodThatHasAnError() {
        //…
        // error， Kraken 。
        presentError() //Woohoo!  ！ ！
    }
}

자, 이제 괜찮아 보여요.우리는 이러한 번거로운 매개 변수를 없앴을 뿐만 아니라, swift 2.0의 새로운 기능으로 프로토콜의 등급에서 Self로 presentError를 기본적으로 실현시켰다 Self UIViewController ， 。 이로써 우리는 Error Pover Renderer를 정말 UIVIew Controller로 여길 수 있고 후자에 대한 확장도 필요 없다!더 좋은 것은 지금부터 Swift가 실행될 때presentError () 방법을 동적 스케줄링이 아닌 정적 스케줄링으로 호출한다는 것이다.대체적인 뜻은 우리가 함수 호출점에서 presentError () 방법에 약간의 성능을 강화했다는 것이다.
원문 전재