java靜態代理模式,舉例給你，看下如何理解：
public class Ts {
public static void main(String[] args) throws Exception {
// 透過中介公司生產一批衣服
ClothingProduct cp = new ProxCompany( new LiNingCompany());
cp.productClothing();
}
/**
* 定義生產一批衣服功能的介面
*
*/
interface ClothingProduct {
void productClothing(); // 有生產一批衣服的功能
* 代理類：中介公司
class ProxCompany implements ClothingProduct {
private ClothingProduct cp ; // 中介公司不會生產衣服，需要找一家真正能生產衣服的公司
ProxCompany(ClothingProduct cp) {
super ();
this . cp = cp;
@Override
public void productClothing() {
System. out .println( "收取1塊錢的中介費" );
cp .productClothing();
* 李寧公司是生產服裝的目標類
class LiNingCompany implements ClothingProduct {
System. out .println( "生產一批衣服。。。。" );
上面程式的做法，使用的模式是靜態代理模式
靜態代理模式在現實程式設計中的弊端：
它的特徵是代理類和目標物件的類都是在編譯期間確定下來的，不利於程式上的擴充套件，上面示例中，如果客戶還想找一個“生產一批鞋子”的工廠，那麼還需要新增加一個代理類和一個目標類。如果客戶還需要很多其他的服務，就必須一一的新增代理類和目標類。那就需要寫很多的代理類和目標類
代理模式到底做了什麼？
我眼中的代理模式只有兩個關注點：協議和代理者
協議定義了一組方法，由某一個類負責實現。
代理者作為某個類的一個屬性，通常是另一個類的例項物件，可以負責完成原來這個類不方便或者無法完成的任務。
首先談一談代理者，在腦中重新回想一下代理模式的實現過程。在頁面B中定義一個代理物件的時候，好像和定義一個普通的property非常類似（除了 weak和id《delegate》>）。這也正是我對代理的概括：代理本來就是一個屬性而已，並沒有非常神秘。
當然，代理者並不只是一個類普通的屬性，否則我只需要重寫一下B的初始化方法即可達到同樣的效果：
self.BVC = [[BViewController alloc]initWithDelegate:self];
然後在BViewController.m中定義一個AViewController *AVC並在初始化方法中賦值即可。
注意到代理者在定義的時候，格式往往是這樣的：
id <SomeDelegate> delegate;
所以我對代理的優勢的理解是：
代理的核心優勢在於解耦
與直接宣告一個屬於某個固定的類的代理者相比，宣告為id的代理者具備兩個明星的優勢。
允許多個不同的類成為本類的代理。試想一下在本文例子中，如果頁面B可以跳轉回N個頁面，如果還是透過宣告一個普通物件的方式，那怎麼辦？
允許代理者的類還不固定。試想一下，UITableView也有delegate，它根本不知道那個類會成為它的代理者。
再看一看協議。協議更加簡單了。協議只是定義了一組方法。在代理模式中，完全可以不用在頁面B中定義一個協議，然後A再去遵循這個協議。直接呼叫A的方法即可。
個人認為協議的優點在於以下幾點：
可以利用Xcode的檢查機制。對於定義為@required的方法，如果實現了協議而沒有實現這個方法，編譯器將會有警告。這樣可以防止因為疏忽，忘記實現某個程式碼的情況，而由於OC的執行時特性，這樣的錯誤往往在執行階段才會導致程式崩潰。
有利於程式碼的封裝。如果一個類，實現了某個協議，那麼這個協議中的方法不必在.h中被宣告，就可以被定義協議的類呼叫。這樣可以減少一個類暴露給外部的方法。
有利於程式的結構化與層次化。一個協議往往是解決問題的某個方法，對於一個其他的不過卻類似的問題，我們只用再次實現協議即可，避免了自己再次構思一組方法。協議的繼承機制使得這一有點更加強大。
說了怎麼多，總結起來只有一句：代理模式並不神秘，只是一個經過了最佳化的小技巧（讓某個類持有另一個類的指標）。代理和協議也只是讓程式耦合度更低，結構感更強而已。
java靜態代理模式,舉例給你，看下如何理解：
public class Ts {
public static void main(String[] args) throws Exception {
// 透過中介公司生產一批衣服
ClothingProduct cp = new ProxCompany( new LiNingCompany());
cp.productClothing();
}
}
/**
* 定義生產一批衣服功能的介面
*
*/
interface ClothingProduct {
void productClothing(); // 有生產一批衣服的功能
}
/**
*
* 代理類：中介公司
*
*/
class ProxCompany implements ClothingProduct {
private ClothingProduct cp ; // 中介公司不會生產衣服，需要找一家真正能生產衣服的公司
ProxCompany(ClothingProduct cp) {
super ();
this . cp = cp;
}
@Override
public void productClothing() {
System. out .println( "收取1塊錢的中介費" );
cp .productClothing();
}
}
/**
*
* 李寧公司是生產服裝的目標類
*
*/
class LiNingCompany implements ClothingProduct {
@Override
public void productClothing() {
System. out .println( "生產一批衣服。。。。" );
}
}
上面程式的做法，使用的模式是靜態代理模式
靜態代理模式在現實程式設計中的弊端：
它的特徵是代理類和目標物件的類都是在編譯期間確定下來的，不利於程式上的擴充套件，上面示例中，如果客戶還想找一個“生產一批鞋子”的工廠，那麼還需要新增加一個代理類和一個目標類。如果客戶還需要很多其他的服務，就必須一一的新增代理類和目標類。那就需要寫很多的代理類和目標類
代理模式到底做了什麼？
我眼中的代理模式只有兩個關注點：協議和代理者
協議定義了一組方法，由某一個類負責實現。
代理者作為某個類的一個屬性，通常是另一個類的例項物件，可以負責完成原來這個類不方便或者無法完成的任務。
首先談一談代理者，在腦中重新回想一下代理模式的實現過程。在頁面B中定義一個代理物件的時候，好像和定義一個普通的property非常類似（除了 weak和id《delegate》>）。這也正是我對代理的概括：代理本來就是一個屬性而已，並沒有非常神秘。
當然，代理者並不只是一個類普通的屬性，否則我只需要重寫一下B的初始化方法即可達到同樣的效果：
self.BVC = [[BViewController alloc]initWithDelegate:self];
然後在BViewController.m中定義一個AViewController *AVC並在初始化方法中賦值即可。
注意到代理者在定義的時候，格式往往是這樣的：
id <SomeDelegate> delegate;
所以我對代理的優勢的理解是：
代理的核心優勢在於解耦
與直接宣告一個屬於某個固定的類的代理者相比，宣告為id的代理者具備兩個明星的優勢。
允許多個不同的類成為本類的代理。試想一下在本文例子中，如果頁面B可以跳轉回N個頁面，如果還是透過宣告一個普通物件的方式，那怎麼辦？
允許代理者的類還不固定。試想一下，UITableView也有delegate，它根本不知道那個類會成為它的代理者。
再看一看協議。協議更加簡單了。協議只是定義了一組方法。在代理模式中，完全可以不用在頁面B中定義一個協議，然後A再去遵循這個協議。直接呼叫A的方法即可。
個人認為協議的優點在於以下幾點：
可以利用Xcode的檢查機制。對於定義為@required的方法，如果實現了協議而沒有實現這個方法，編譯器將會有警告。這樣可以防止因為疏忽，忘記實現某個程式碼的情況，而由於OC的執行時特性，這樣的錯誤往往在執行階段才會導致程式崩潰。
有利於程式碼的封裝。如果一個類，實現了某個協議，那麼這個協議中的方法不必在.h中被宣告，就可以被定義協議的類呼叫。這樣可以減少一個類暴露給外部的方法。
有利於程式的結構化與層次化。一個協議往往是解決問題的某個方法，對於一個其他的不過卻類似的問題，我們只用再次實現協議即可，避免了自己再次構思一組方法。協議的繼承機制使得這一有點更加強大。
說了怎麼多，總結起來只有一句：代理模式並不神秘，只是一個經過了最佳化的小技巧（讓某個類持有另一個類的指標）。代理和協議也只是讓程式耦合度更低，結構感更強而已。