設計模式代理怎麼學

A. java中常用到得設計模式有哪幾種

一共23種設計模式！

按照目的來分，設計模式可以分為創建型模式、結構型模式和行為型模式。
創建型模式用來處理對象的創建過程；結構型模式用來處理類或者對象的組合；行為型模式用來對類或對象怎樣交互和怎樣分配職責進行描述。

創建型模式用來處理對象的創建過程，主要包含以下5種設計模式：
 工廠方法模式（Factory Method Pattern）
 抽象工廠模式（Abstract Factory Pattern）
 建造者模式（Builder Pattern）
 原型模式（Prototype Pattern）
 單例模式（Singleton Pattern）

結構型模式用來處理類或者對象的組合，主要包含以下7種設計模式：
 適配器模式（Adapter Pattern）
 橋接模式（Bridge Pattern）
 組合模式（Composite Pattern）
 裝飾者模式（Decorator Pattern）
 外觀模式（Facade Pattern）
 享元模式（Flyweight Pattern）
 代理模式（Proxy Pattern）

行為型模式用來對類或對象怎樣交互和怎樣分配職責進行描述，主要包含以下11種設計模式：
 責任鏈模式（Chain of Responsibility Pattern）
 命令模式（Command Pattern）
 解釋器模式（Interpreter Pattern）
 迭代器模式（Iterator Pattern）
 中介者模式（Mediator Pattern）
 備忘錄模式（Memento Pattern）
 觀察者模式（Observer Pattern）
 狀態模式（State Pattern）
 策略模式（Strategy Pattern）
 模板方法模式（Template Method Pattern）
 訪問者模式（Visitor Pattern）

推薦你一本好書：《軟體秘笈：設計模式那點事》，裡面講解的23中設計模式例子很生動，容易理解，還有JDK中設計模式應用情況，看了收獲挺大的！網路裡面搜「設計模式」，第一條中設計模式網路中就有首推該圖書，瀏覽量在20幾萬以上的，不會錯的。好東西大家一起分享！
祝你早日學會設計模式！

B. iOS 設計模式（一）-代理模式

代理模式是一種消息傳遞方式，一個完整的代理模式包括：委託對象、代理對象和協議。
協議：用來指定代理雙方可以做什麼，必須做什麼。
委託對象：根據指定的協議，指定代理去完成什麼功能。
代理對象：根據指定的協議，完成委託方需要實現的功能。

從上圖中可以看到三方之間的關系，在實際應用中通過協議來規定代理雙方的行為，協議中的內容一般都是方法列表，當然也可以定義屬性。

協議是公共的定義，如果只是某個類使用，我們常做的就是寫在某個類中。如果是多個類都是用同一個協議，建議創建一個Protocol文件，在這個文件中定義協議。遵循的協議可以被繼承，例如我們常用的 UITableView ，由於繼承自 UIScrollView 的緣故，所以也將 UIScrollViewDelegate 繼承了過來，我們可以通過代理方法獲取 UITableView 偏移量等狀態參數。

協議只能定義公用的一套介面，類似於一個約束代理雙方的作用。但不能提供具體的實現方法，實現方法需要代理對象去實現。協議可以繼承其他協議，並且可以繼承多個協議，在iOS中對象是不支持多繼承的，而協議可以多繼承。

協議有兩個修飾符 @optional 和 @required ，創建一個協議如果沒有聲明，默認是 @required 狀態的。這兩個修飾符只是約定代理是否強制需要遵守協議，如果 @required 狀態的方法代理沒有遵守，會報一個黃色的警告，只是起一個約束的作用，沒有其他功能。

無論是 @optional 還是 @required ，在委託方調用代理方法時都需要做一個判斷，判斷代理是否實現當前方法，否則會導致崩潰。

在iOS中代理的本質就是代理對象內存的傳遞和操作，我們在委託類設置代理對象後，實際上只是用一個id類型的指針將代理對象進行了一個弱引用。委託方讓代理方執行操作，實際上是在委託類中向這個id類型指針指向的對象發送消息，而這個id類型指針指向的對象，就是代理對象。

通過上面這張圖我們發現，其實委託方的代理屬性本質上就是代理對象自身，設置委託代理就是代理屬性指針指向代理對象，相當於代理對象只是在委託方中調用自己的方法，如果方法沒有實現就會導致崩潰。從崩潰的信息上來看，就可以看出來是代理方沒有實現協議中的方法導致的崩潰。

而協議只是一種語法，是聲明委託方中的代理屬性可以調用協議中聲明的方法，而協議中方法的實現還是有代理方完成，而協議方和委託方都不知道代理方有沒有完成，也不需要知道怎麼完成。

由於代理對象使用強引用指針，引用創建的委託方對象，並且成為委託對象的代理。這就會導致委託對象的delegate屬性強引用代理對象，導致循環引用的問題，最終兩個對象都無法正常釋放。
我們將委託對象的delegate屬性，設置為弱引用屬性。
weak 和 assign 是一種「非擁有關系」的指針，通過這兩種修飾符修飾的指針變數，都不會改變被引用對象的引用計數。但是在一個對象被釋放後， weak 會自動將指針指向 nil ，而 assign 則不會。在iOS中，向 nil 發送消息時不會導致崩潰的，所以 assign 就會導致野指針的錯誤 unrecognized selector sent to instance 。
所以我們如果修飾代理屬性，還是用 weak 修飾，比較安全。

C. 設計模式都有哪些

總體來說設計模式分為三大類：

一、創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

二、結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

三、行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

1、工廠方法模式：

定義一個用於創建對象的介面，讓子類決定實例化哪一個類。Factory Method 使一個類的實例化延遲到其子類。

工廠模式有一個問題就是，類的創建依賴工廠類，也就是說，如果想要拓展程序，必須對工廠類進行修改，這違背了閉包原則，所以，從設計角度考慮，有一定的問題，這就用到工廠方法模式。

創建一個工廠介面和創建多個工廠實現類，這樣一旦需要增加新的功能，直接增加新的工廠類就可以了，不需要修改之前的代碼。

2、抽象工廠模式：

提供一個創建一系列相關或相互依賴對象的介面，而無需指定它們具體的類。抽象工廠需要創建一些列產品，著重點在於"創建哪些"產品上，也就是說，如果你開發，你的主要任務是劃分不同差異的產品線，並且盡量保持每條產品線介面一致，從而可以從同一個抽象工廠繼承。

3、單例模式：

單例對象（Singleton）是一種常用的設計模式。在Java應用中，單例對象能保證在一個JVM中，該對象只有一個實例存在。這樣的模式有幾個好處：

（1）某些類創建比較頻繁，對於一些大型的對象，這是一筆很大的系統開銷。

（2）省去了new操作符，降低了系統內存的使用頻率，減輕GC壓力。

（3）有些類如交易所的核心交易引擎，控制著交易流程，如果該類可以創建多個的話，系統完全亂了。（比如一個軍隊出現了多個司令員同時指揮，肯定會亂成一團），所以只有使用單例模式，才能保證核心交易伺服器獨立控制整個流程。

4、建造者模式：

將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

5、原型模式：

原型模式雖然是創建型的模式，但是與工程模式沒有關系，從名字即可看出，該模式的思想就是將一個對象作為原型，對其進行復制、克隆，產生一個和原對象類似的新對象。本小結會通過對象的復制，進行講解。在Java中，復制對象是通過clone()實現的，先創建一個原型類。

6、適配器模式：

適配器模式將某個類的介面轉換成客戶端期望的另一個介面表示，目的是消除由於介面不匹配所造成的類的兼容性問題。主要分為三類：類的適配器模式、對象的適配器模式、介面的適配器模式。

7、裝飾器模式：

顧名思義，裝飾模式就是給一個對象增加一些新的功能，而且是動態的，要求裝飾對象和被裝飾對象實現同一個介面，裝飾對象持有被裝飾對象的實例。

8、代理模式：

代理模式就是多一個代理類出來，替原對象進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的信息掌握的不夠全面，希望找一個更熟悉的人去幫你做，此處的代理就是這個意思。

9、外觀模式：

外觀模式是為了解決類與類之家的依賴關系的，像spring一樣，可以將類和類之間的關系配置到配置文件中，而外觀模式就是將他們的關系放在一個Facade類中，降低了類類之間的耦合度，該模式中沒有涉及到介面。

10、橋接模式：

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的JDBC橋DriverManager一樣。

JDBC進行連接資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的代碼，甚至絲毫不用動，原因就是JDBC提供統一介面，每個資料庫提供各自的實現，用一個叫做資料庫驅動的程序來橋接就行了。

11、組合模式：

組合模式有時又叫部分-整體模式在處理類似樹形結構的問題時比較方便。使用場景：將多個對象組合在一起進行操作，常用於表示樹形結構中，例如二叉樹，數等。

12、享元模式：

享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候可以減少內存的開銷，通常與工廠模式一起使用。

13、策略模式：

策略模式定義了一系列演算法，並將每個演算法封裝起來，使其可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計一個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計一個抽象類（可有可無，屬於輔助類），提供輔助函數。

14、模板方法模式：

一個抽象類中，有一個主方法，再定義1...n個方法，可以是抽象的，也可以是實際的方法，定義一個類，繼承該抽象類，重寫抽象方法，通過調用抽象類，實現對子類的調用。

15、觀察者模式：

觀察者模式很好理解，類似於郵件訂閱和RSS訂閱，當我們瀏覽一些博客或wiki時，經常會看到RSS圖標，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。

其實，簡單來講就一句話：當一個對象變化時，其它依賴該對象的對象都會收到通知，並且隨著變化！對象之間是一種一對多的關系。

16、迭代子模式：

顧名思義，迭代器模式就是順序訪問聚集中的對象，一般來說，集合中非常常見，如果對集合類比較熟悉的話，理解本模式會十分輕松。這句話包含兩層意思：一是需要遍歷的對象，即聚集對象，二是迭代器對象，用於對聚集對象進行遍歷訪問。

17、責任鏈模式：

責任鏈模式，有多個對象，每個對象持有對下一個對象的引用，這樣就會形成一條鏈，請求在這條鏈上傳遞，直到某一對象決定處理該請求。但是發出者並不清楚到底最終那個對象會處理該請求，所以，責任鏈模式可以實現，在隱瞞客戶端的情況下，對系統進行動態的調整。

18、命令模式：

命令模式的目的就是達到命令的發出者和執行者之間解耦，實現請求和執行分開。

19、備忘錄模式：

主要目的是保存一個對象的某個狀態，以便在適當的時候恢復對象，個人覺得叫備份模式更形象些，通俗的講下：假設有原始類A，A中有各種屬性，A可以決定需要備份的屬性，備忘錄類B是用來存儲A的一些內部狀態，類C呢，就是一個用來存儲備忘錄的，且只能存儲，不能修改等操作。

20、狀態模式：

狀態模式在日常開發中用的挺多的，尤其是做網站的時候，我們有時希望根據對象的某一屬性，區別開他們的一些功能，比如說簡單的許可權控制等。

21、訪問者模式：

訪問者模式把數據結構和作用於結構上的操作解耦合，使得操作集合可相對自由地演化。訪問者模式適用於數據結構相對穩定演算法又易變化的系統。因為訪問者模式使得演算法操作增加變得容易。

若系統數據結構對象易於變化，經常有新的數據對象增加進來，則不適合使用訪問者模式。訪問者模式的優點是增加操作很容易，因為增加操作意味著增加新的訪問者。訪問者模式將有關行為集中到一個訪問者對象中，其改變不影響系統數據結構。其缺點就是增加新的數據結構很困難。

22、中介者模式：

中介者模式也是用來降低類類之間的耦合的，因為如果類類之間有依賴關系的話，不利於功能的拓展和維護，因為只要修改一個對象，其它關聯的對象都得進行修改。

如果使用中介者模式，只需關心和Mediator類的關系，具體類類之間的關系及調度交給Mediator就行，這有點像spring容器的作用。

23、解釋器模式：

解釋器模式一般主要應用在OOP開發中的編譯器的開發中，所以適用面比較窄。

(3)設計模式代理怎麼學擴展閱讀：

介紹三本關於設計模式的書：

1、《設計模式：可復用面向對象軟體的基礎》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 機械工業出版社

2、《軟體秘笈：設計模式那點事》

作者：鄭阿奇

出版社：電子工業出版社

3、《設計模式：基於C#的工程化實現及擴展》

作者：王翔

出版社：電子工業出版社

D. 軟體開發中常用的設計模式有哪些

設計模式主要分三個類型:創建型、結構型和行為型。

其中創建型有：

一、Singleton，單例模式：保證一個類只有一個實例，並提供一個訪問它的全局訪問點

二、Abstract Factory，抽象工廠：提供一個創建一系列相關或相互依賴對象的介面，而無須指定它們的具體類。

三、Factory Method，工廠方法：定義一個用於創建對象的介面，讓子類決定實例化哪一個類，Factory Method使一個類的實例化延遲到了子類。

四、Builder，建造模式：將一個復雜對象的構建與他的表示相分離，使得同樣的構建過程可以創建不同的表示。

五、Prototype，原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型來創建新的對象。

行為型有：

六、Iterator，迭代器模式：提供一個方法順序訪問一個聚合對象的各個元素，而又不需要暴露該對象的內部表示。

七、Observer，觀察者模式：定義對象間一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知自動更新。

八、Template Method，模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中，TemplateMethod使得子類可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。

九、Command，命令模式：將一個請求封裝為一個對象，從而使你可以用不同的請求對客戶進行參數化，對請求排隊和記錄請求日誌，以及支持可撤銷的操作。

十、State，狀態模式：允許對象在其內部狀態改變時改變他的行為。對象看起來似乎改變了他的類。

十一、Strategy，策略模式：定義一系列的演算法，把他們一個個封裝起來，並使他們可以互相替換，本模式使得演算法可以獨立於使用它們的客戶。

十二、China of Responsibility，職責鏈模式：使多個對象都有機會處理請求，從而避免請求的送發者和接收者之間的耦合關系

十三、Mediator，中介者模式：用一個中介對象封裝一些列的對象交互。

十四、Visitor，訪問者模式：表示一個作用於某對象結構中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用於這個元素的新操作。

十五、Interpreter，解釋器模式：給定一個語言，定義他的文法的一個表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。

十六、Memento，備忘錄模式：在不破壞對象的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。
結構型有：

十七、Composite，組合模式：將對象組合成樹形結構以表示部分整體的關系，Composite使得用戶對單個對象和組合對象的使用具有一致性。

十八、Facade，外觀模式：為子系統中的一組介面提供一致的界面，fa?ade提供了一高層介面，這個介面使得子系統更容易使用。

十九、Proxy，代理模式：為其他對象提供一種代理以控制對這個對象的訪問

二十、Adapter,適配器模式：將一類的介面轉換成客戶希望的另外一個介面，Adapter模式使得原本由於介面不兼容而不能一起工作那些類可以一起工作。

二十一、Decrator，裝飾模式：動態地給一個對象增加一些額外的職責，就增加的功能來說，Decorator模式相比生成子類更加靈活。

二十二、Bridge，橋模式：將抽象部分與它的實現部分相分離，使他們可以獨立的變化。

二十三、Flyweight，享元模式

23種設計模式要在這里詳細的都說一遍內容實在太多了啊，推薦你一本好書《軟體秘笈：設計模式那點事》，裡面講解的23中設計模式例子很生動，容易理解，還有JDK中設計模式應用情況，看了收獲挺大的！網路裡面搜「設計模式」，第一條中設計模式網路中就有首推該圖書，瀏覽量在20幾萬以上的，不會錯的。

E. 設計模式——代理模式

代理模式（Proxy Pattern）是一個使用率非常高的模式。
定義： Provide a surrogate or placeholder for another object to control access to it. (為其對象提供一種代理以控制這個對象的訪問)

代理模式也叫委託模式，它是一項基本的設計技巧。許多其他的模式，如狀態模式、策略模式、訪問者模式本質上是在更特殊的場合採用了委託模式，而且在日常應用中，代理模式可以提供非常好的訪問控制。

三個角色的定義

抽象主題類可以是抽象類也可以是介面，是一個最普通的業務類型定義，無特殊要求。

也叫做被委託的角色、被代理的角色。是業務邏輯的具體執行者。

也叫委託類、代理類。它負責對真實角色的應用，把所以抽象主題定義的方法限制委託給真實主題角色實現，並且在真實主題角色處理完畢前後做預處理和善後工作。

一個代理類可以代理多個被委託者或者被代理者，因此一個代理者具體代理哪個真實主題角色，是由場景類決定的。在通常情況下，一個介面只需要一個代理類就可以了，具體代理哪個實現類由高層模塊決定，也就是在代理類的構造函數中傳遞被代理者。

類似現實生活中買房子的中介，打官司的律師。你不想參與中間過程的是是非非。減輕用戶的負擔。代理模式使用場景非常多。最典型的是Spring AOP中的動態代理。

普通代理就是我們要知道代理的存在，也就是類似GamePlayerProxy這個代理類的存在，然後才能訪問。
普通代理的要求就是客戶端只能訪問代理角色，而不能訪問真實角色。以游戲代練為例子，

GamePlayer的構造函數增加了_gamePlayer參數，而代理角色則只要傳入代理者名字即可，而不需要說是替哪個對象做代理

在構造函數中，傳來進來一個IGaemPlayer對象，檢查誰能創建真實的角色，或者做出別的限制。

僅僅修改了構造函數，傳遞進來一個代理者名稱，即可進行代理，在這種改造下，系統更加簡潔，調用者只知道代理的存在就行，不用知道代理了誰。

在該模式下，調用者只知道代理而不知道真實的角色是誰，屏蔽了真實角色的變更對高層模塊的影響，真實的主題角色想怎麼修改都可以，對高層次的模塊沒有任何的影響，只要你實現了介面所對應的方法，該模式非常適合對擴展性要求較高的場合。

強制代理是要「強制」，必須通過真實角色查找到代理角色，否則不能進行訪問。無論是通過代理類還是直接new一個主題角色類，都不能訪問，只有通過真實角色指定的代理類才能訪問，也就是說由真實的角色管理代理角色。例如你和一個明星比較熟，你直接找明星幫忙要見導演，但是明星說她比較忙，讓你找她的經紀人。你本來想繞過她的代理，誰知道她返回的還是她的代理，這就是強制代理。你可以不知道代理的存在，但是你的所作所為還是需要代理為你提供服務。

強制代理的概念就是要從真實的角色查找到代理角色，不允許直接訪問真實角色。高層模塊只要調用 getProxy() 就可以訪問真實角色的所以方法，它根本不需要產生一個代理出來，代理的管理已經由真實角色自己完成。

一個類可以實現多個介面，完成不同任務的整合。也就是說代理類不僅僅可以實現主題介面，也可以實現其他介面完成不同的任務，而且代理的目的是在目標對象方法的基礎上作增強，這種增強的本質通常就是對目標對象的方法進行攔截合過濾。

動態代理

F. Android 進階-設計模式-靜態代理和動態代理（aop原理）

Proxy的newProxyInstance方法會根據傳入的類載入器動態生成代理對象實例，生成的代理對象會繼承Proxy類並實現傳入的介面列表，這里的類載入器是小明的ClassLoader，即真實對象的類載入器，而介面列表則是IComputer，傳入的IComputer的Class對象，除了這個兩個參數，還傳入了動態代理類InvocationHandler實例，這樣Proxy類在創建代理對象的實例時就會把這個InvocationHandler引用傳給代理對象，接下來當我們調用代理對象的方法時，這個方法的處理邏輯就會委託給InvocationHandler實例的invoke方法執行，invoke方法中就會通過反射調用我們真實對象的方法。

登錄介面ILogin 驗證登錄 只有登陸後才能執行該方法

創建MyInvocationHandler 來監聽代理類 方法的執行

在測試的activity中 使用：

app gradle 配置

在 project gradle

Login

LoginAspect

使用