就像MVC是蘋果提供的UI框架里 自帶的設(shè)計模式一樣巧鸭，代理設(shè)計模式也充斥著蘋果的編程里曼追，拋開系統(tǒng)框架不說，當我們要自己寫一個代理的時候大家都知道在RAC下有個循環(huán)應(yīng)用問題饺藤；即A類 持有B類剑辫，B類持有一個代理干旧，這個代理指向A類，這個時候就形成了循環(huán)妹蔽，為了避免這個問題椎眯，我們會有意識的把代理設(shè)置成weak，這樣就能保證A類和B類的正確釋放胳岂。
那么問題來了:
大概的意思就是說 swift的協(xié)議考慮到可能用 struct盅视、enum準守的可能性，不能使用weak修飾旦万，這是swift強大的面向協(xié)議編程理念的基礎(chǔ)闹击，這個時候大家肯定就會想到轉(zhuǎn)換成OC的protocol 在協(xié)議前面加上 @objc
這往往的確能解決問題 但是 swift 作為一個獨立的語言這么依靠OC肯定是不可能的，于是有了
這樣這個協(xié)議就只能由 class 準守了成艘，這就相當于OC里的協(xié)議了赏半，也是大家最熟悉的協(xié)議，就是用來解決class之間的種種問題的協(xié)議了淆两，運用老的編程思路和思想這個問題似乎已經(jīng)解決了断箫，但還差了點，swift的面相協(xié)議編程思想不能這么弱秋冰，這個時候我們有期望struct仲义，或者enum來準守協(xié)議怎么辦
回到 我們解決循環(huán)引用的問題上來[A持有屬性B(持有屬性delegate:A)]，我們是因為三個引用循環(huán)里需要其中一個引用需要用weak打破,自然在代理用weak是經(jīng)過前人深思熟慮和實踐的結(jié)果剑勾，如果不在此處使用埃撵，那么就只能是在A持有B這個地方了，那么為什么不這么做呢虽另，那是因為A持有B是一個明顯的上下級或者父子級關(guān)系暂刘，所以 往往A必須是到B是一定存在的我們才能做很多事情，但是 如果這是個視圖那么情況就很不同了捂刺，首先 當一個視圖被add的時候就一定會有個強引用谣拣， 所以 子視圖屬性完全可以用weak修飾，如果你是用的storyboard/xib這樣的東西 就更不用擔心了族展，當你拖拽到代碼里的時候 會看見他是用weak修飾的森缠，因為storyboard/xib添加的視圖都是已經(jīng)被強引用了的。
因此當我們碰見protocol時就需要更仔細的思考了仪缸，如果這是一個修飾class的協(xié)議還是一個objc協(xié)議贵涵，還是一個可以修飾enum/struct的協(xié)議，來使用不同的方式完成我們的程序。
