? ? ? 這段時間用Swift寫項目時候便發現它的構造函數相比OC真的是復雜了許多,加了很多的限制和條件,不過這么設計肯定有它的道理..穩定性和可選類型的加入可能是主要原因..
? ? ? 通過<Swift Programming Language>和最近項目實戰對我目前遇到的寫構造器的各種場景和對應問題做個總結..同時用代碼驗證一下書中所說的各種限制...(只討論class,struct和enum是值類型不支持繼承)
Swift Programming Language 中對"構造過程"的描述
1. 類和結構體在創建實例時，必須為所有存儲型屬性設置合適的初始值。存儲型屬性的值不能處于一個未知的狀態.
在OC中我們不需要考慮屬性的初始值是因為屬性默認值就為nil或者0...然而Swift中有了可選類型的概念它并不會這么做,對于可選類型的屬性如果不初始化值它默認為nil..但是對于非可選類型它永遠不可以為nil,我們需要手動在這個實例出現之前(構造器中或聲明時候)為它這些屬性賦初始值,以保證這個實例每一個屬性都合法..對于計算屬性因為必須實現get方法相當于也有初始值.?
注: Swift 的nil和 Objective-C 中的nil并不一樣。在 Objective-C 中，nil是一個指向不存在對象的指針。在 Swift 中，nil不是指針——它是一個確定的值，用來表示值缺失。任何類型的可選狀態都可以被設置為nil，不只是對象類型。
OC中一個int 類型的屬性沒有初始值時候默認為0...但Swift的Int屬性聲明為可選類型(Int?)它也可能是nil,表示目前沒有值.
2. 如果結構體或類的所有屬性都有默認值，同時沒有自定義的構造器，那么 Swift 會給這些結構體或類提供一個默認構造器
這一條很好理解...但是有一種情況是這個類有父類,并且父類有指定構造器...那么這個類會繼承父類的指定構造器,相當于它具有了指定構造器.這種時候雖然沒有自定義構造器,但其實Swift并不會給它默認的構造器了.
3. 類里面的所有存儲型屬性——包括所有繼承自父類的屬性——都必須在構造過程中設置初始值。
這與第1條描述的一件事情,因為子類會繼承父類的屬性,所以子類實例的屬性還是要全部就有初始值.
4.1 指定構造器必須調用其直接父類的的指定構造器
一個子類實例的屬性全都有初始值的前提除了子類定義的屬性全部賦初值當然還要給從父類繼承來的屬性賦初值..調用父類的指定構造器可以保證父類的所有屬性成功賦初值,進而根據父類鏈繼續往上調用父類的構造器來完成這個子類實例所有屬性的賦值.?
注: 詳細請看下面"類的兩段式構造"
問題:為什么限定必須是父類的指定構造器而不能是一個便利構造器呢?最終便利構造器會調用到一個指定構造器,父類的屬性還是會全部初始化..這樣規定的原因回頭再研究.
4.2 便利構造器必須調用同類中定義的其它構造器。
4.3 便利構造器必須最終導致一個指定構造器被調用。
所謂便利構造器,意思也是在屬性全部初始化的基礎上再給添加一些其它的賦值,或者是給可選類型通過參數賦值..所以4.3調用一個指定構造器是必需的了..4.2是說只能調用同類中的.看來便利構造器還是對自身類的初始方法,在便利構造器中調用super構造器方法會報錯.
對第4條,做一個驗證.
所以在給一個類添加extension的時候,通常都是使用便利構造器,先調用自身的某一個指定構造器然后再這個基礎上添加某些屬性...例如給一個UIButton添加快捷創建方式:
Swift的兩段式構造過程
第一個階段，每個存儲型屬性被引入它們的類指定一個初始值。當每個存儲型屬性的初始值被確定后，第二階段開始，它給每個類一次機會，在新實例準備使用之前進一步定制它們的存儲型屬性。
這個翻譯的說實話我感覺就一個意思..就是存儲型屬性要首先有個初始值.因為其它語言的屬性都是有默認值的,swift的屬性不聲明為可選類型必須要有初始值所以加了這么一個第一階段...
第一階段：
1. 程序調用子類的某個構造器
2. 為實例分配內存, 此時實例的內存還沒有被初始化
3. 指定構造器確保子類定義的所有實例存儲屬性都已被賦初值
4. 指定構造器將調用父類的構造器, 完成父類定義的實例存儲屬性的初始化
5. 沿著調用父類構造器的構造器鏈一直往上執行, 直到到達構造器鏈的最頂部
第二階段：
1. 沿著繼承樹往下, 構造器此時可以修改實例屬性和訪問self, 甚至可以調用實例方法
2. 最后, 構造器鏈中的便利構造器都有機會定制實例和使用self
Swift 編譯器將執行 4 種有效的安全檢查，以確保兩段式構造過程能不出錯地完成:
直接看它所說的4種安全檢查吧.
安全檢查1: 指定構造器必須保證它所在類引入的所有屬性都必須先初始化完成，之后才能將其它構造任務向上代理給父類中的構造器。
為什么類中所有的屬性必須初始化完成才可以調用父類的構造任務呢?
一個對象的內存只有在其所有存儲型屬性確定之后才能完全初始化。為了滿足這一規則，指定構造器必須保證它所在類引入的屬性在它往上代理之前先完成初始化。
這個應該不是原因..因為文檔還說:一旦父類中所有屬性都有了初始值，實例的內存被認為是完全初始化..所以super之后再給子類的屬性賦值為什么不行呢? ? ? 答案?參考
安全檢查2: 指定構造器必須先向上代理調用父類構造器，然后再為繼承的屬性設置新值。如果沒這么做，指定構造器賦予的新值將被父類中的構造器所覆蓋。
事實是如果不這么做,編譯器會直接報錯.
安全檢查3：便利構造器必須先調用同一個類的其他構造器, 然后才能對屬性賦值如果沒這么做，便利構造器賦予的新值將被同一類中其它指定構造器所覆蓋。
安全檢查4: 構造器在第一階段構造完成之前，不能調用任何實例方法，不能讀取任何實例屬性的值，不能引用self作為一個值
因為第一階段完成之前內存初始化還沒有成功,顯然還沒有self這個東西..也沒有那些示例屬性呢.
在項目中遇到的一個棘手問題
需求是一個逆向傳值,,只不過這個閉包是在初始化構造函數里直接賦值..并且還要在閉包中能訪問當前實例屬性.
閉包作為構造器參數傳值同其它類型作為參數時候的語法相同..因為閉包也是一種數據類型嘛
但是想要給傳來的閉包直接進行賦值并且能在閉包中訪問屬性需要將這個帶有閉包的對象使用lazy 懶加載...如果不用lazy,此類中這個屬性在初始化的時候類實例并沒有構造完成,使用了lazy意味著這個屬性在類實例用到的時候才會初始化,所以這個時候當前類實例肯定是存在的了.才可以在閉包中使用self..
好處:很多UI控件用懶加載會緩解加載類時候的壓力.
場景:屬性本身依賴于外部因素才能初始化;可能會進行大量CPU消耗;不一定會在什么時候用到,一個事件觸發才會用到;
特別注意,項目中我在閉包中使用self.age 編譯器一直會報錯...最后找了半天原因是因為我沒有給這個懶加載的屬性設置"類型描述" 也就是冒號后面那個..這可能是編譯器的推斷出現了問題,看來以后沒事還是加上類型描述吧.
