關於「幽靈架構」的補充說明1 協議中的方法定義

//檢視使用的協議 protocol viewtype //資料使用的協議 protocol modeltype //定義預設方法givedata extension modeltype

}

首先來回答第乙個問題，為什麼getdata被定義在協議viewtype的定義中，只有函式宣告沒有實現，而givedata被定義在modeltype的擴充套件中，並且附帶了方法的具體實現。請看下面的例子：

protocol sharedstring
extension sharedstring
func methodwithoutoverride()
}

兩個方法都被定義在了協議的擴充套件中，現在讓string遵守該協議，string將免費獲得這兩個方法的實現，並且在string的擴充套件中重寫methodforoverride()的實現，輸出string本身的值：

extension string
:sharedstring
}

現在使用字面量生成乙個string型別，然後呼叫方法methodforoverride：

"hello"
.methodforoverride()

輸出的結果是「hello」，這符合我們的預期，這裡使用字面量生成了乙個例項，依靠了型別推斷的預設值，「hello」是sting型別的，也就是sharedstring的具體遵守者，所以呼叫了被重寫的methodforoverride版本。swift中的方法過載不僅可以根據引數進行過載，還可以根據返回值型別進行過載，只需要修改返回值的宣告即可。這裡我們修改「hello」的上下文：

//用乙個字面量來跟大家打個招呼
"hello".methodforoverride()
//hello是sharedstring型別的
let hello:sharedstring = "hello"
hello.methodforoverride()

hello是sharedstring型別的，雖然hello和「hello」的字面量是相同的，列印結果如下：

有趣的是在協議的擴充套件中宣告的方法定義會被保留，更有趣的是另乙個方法methodwithoutoverride()，這個方法在方法體中呼叫了另乙個方法methodforoverride，現在對「hello」和hello呼叫方法methodwithoutoverride：

"hello"
.methodwithoutoverride()
hello.methodwithoutoverride()

結果如下：

結果有點出乎意料，雖然我們在協議遵守者的定義中重寫了方法methodforoverride，定義在協議擴充套件中的另乙個方法只會使用methodforoverride的預設版本的實現，這是協議擴充套件的靜態特性。現在把methodforoverride的宣告從協議的擴充套件中挪到協議的宣告中：

protocol sharedstring
extension sharedstring
func methodwithoutoverride()
}

現在無論你使用「hello」還是hello呼叫methodforoverride()和methodwithoutoverride()都只會輸出重寫後的結果。

結論：把需要被重寫的方法宣告在協議的宣告中是一種刻意的做法，我們希望該方法被重寫，回到架構上，getdata負責不同的view處理獲得的model，view的型別非常多，所以getdata的格式無法統一到乙個預設的方法實現中，我們需要getdata被具體的view所重寫，為了強制這種意圖，getdata甚至沒有乙個預設的實現方法體。根據swift的協議規則，協議遵守者需要實現協議中的所有方法，所以getdata一定會有具體宣告。而前文也總結過，對於modeltype中的givedata這個方法的功能非常統一，即向view傳遞model，所以統一到同乙個方法實現中，並且我們不希望這個方法被重寫，因為重寫會破壞getdata中的邏輯，所以把方法宣告寫在了協議的擴充套件中。

最後需要說明的是「幽靈架構」這個名字只是想表達****的愉悅，其實名字本身並不重要。

關於「幽靈架構」的補充說明1 協議中的方法定義

關於協議的說明

8 關於開發和實施的補充說明

關於《程式設計之美》稿酬捐贈的補充說明

關於「幽靈架構」的補充說明1 協議中的方法定義

關於協議的說明

8 關於開發和實施的補充說明

關於《程式設計之美》稿酬捐贈的補充說明

相關推薦