Java靜態代理和iOS代理模式這兩個概念的理解上的疑惑|ios代理方法怎麼寫

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 delegate；所以我對代理的優勢的理解是：代理的核心優勢在於解耦與直接聲明一個屬於某個固定的類的代理者相比，聲明爲id的代理者具備兩個明星的優勢。

允許多個不同的類成爲本類的代理。試想一下在本文例子中，如果頁面B可以跳轉回N個頁面，如果還是透過聲明一個普通對象的方式，那怎麼辦？允許代理者的類還不固定。

試想一下，UITableView也有delegate，它根本不知道那個類會成爲它的代理者。再看一看協議。

協議更加簡單了。協議只是定義了一組方法。

在代理模式中，完全可以不用在頁面B中定義一個協議，然後A再去遵循這個協議。直接調用A的方法即可。

個人認爲協議的優點在於以下幾點：可以利用Xcode的檢查機制。對於定義爲@required的方法，如果實現了協議而沒有實現這個方法，編譯器將會有警告。

這樣可以防止因爲疏忽，忘記實現某個代碼的情況，而由於OC的執行時特性，這樣的錯誤往往在執行階段纔會導致程序崩潰。有利於代碼的封裝。

如果一個類，實現了某個協議，那麼這個協議中的方法不必在.h中被聲明，就可以被定義協議的類調用。這樣可以減少一個類暴露給外部的方法。

有利於程序的結構化與層次化。一個協議往往是解決問題的某個方法，對於一個其他的不過卻類似的問題，我們只用再次實現協議即可，避免了自己再次構思一組方法。

協議的繼承機制使得這一有點更加強大。說了怎麼多，總結起來只有一句：代理模式並不神祕，只是一個經過了優化的小技巧（讓某個類持有另一個類的指針）。

代理和協議也只是讓程序耦合度更低，結構感更強而已。

QQ代理設定方法：

QQ代理有兩個類型可以選擇：SOCK5代理服務器和HTTP代理服務器。

(1)QQ登陸對話框中的設定

在QQ登陸介面點擊網絡設定→出現的下拉列表中選擇你的需要的代理類型→地址：填上你收集的代理服務器IP（“***.***.***.***形式的”）

→端口：填上你找到的代理服務器的端口參數→把用戶和密碼框填上代理服務器提供的用戶名和密碼（一般免費代理是沒有用戶名和密碼的，

那麼不用填）。

例如你收集 到的代理服務器是127.0.0.1:80那麼設定時地址填：127.0.0.1，端口填80，注意沒有前面的冒號。

好了現在基本設定好了，你可以測試一下你的代理服務器是否工作正常，

點擊測試。假如出現“代理服務器正常”，則這個代理是可用的，正常就可以登陸你QQ了。假如出現“無法連接代理服務器”，則說明這個代

理不能使用，重新輸入另外的代理參數，重新測試。

(2)QQ在執行時的代理設定

點擊“選單”→“系統設定”→“代理設定”

其設定與上面的設定一樣，不過要使剛剛輸入的參數生效，必須下線一次，再上線，這樣才能改變QQ的傳輸狀態，使代理生效。

二：IE瀏覽器的代理設定方法：

1。選單→“工具”→““Internet選項（O）”。

2。選“連接”，單擊“設定（S）。” →““代理服務器”→““對此連接使用代理服務器”→填上HTTP的地址和端口。

3。如果有如FTP/SOCKS/HTTP等更齊全的代理數據，，可單擊“進階（C）。”，分別填入對應的代理數據。（這項一般都沒有，用不着填）

4。現在差不多就OK了。。

首先得描述一下各個證書的定位，作用，這樣在製作的時候心中有譜，對整個流程的把握也會準確一些；

1、開發者證書（分爲開發和發佈兩種，類型爲ios Development,ios Distribution），這個是最基礎的，不論是真機調試，還是上傳到appstore都是需要的，是一個基證書，用來證明自己開發者身份的；

2、appID，這是每一個應用的獨立標識，在設定項中可以配置該應用的權限，比如是否用到了PassBook,GameCenter，以及更常見的push服務，如果選中了push服務，那麼就可以創建生成下面第3條所提到的推送證書，所以，在所有和推送相關的配置中，首先要做的就是先開通支援推送服務的appID;

3、推送證書（分爲開發和發佈兩種，類型分別爲APNs Development ios,APNs Distribution ios），該證書在appID配置中創建生成，和開發者證書一樣，安裝到開發電腦上；

4、Provisioning Profiles，這個東西是很有蘋果特色的一個東西，我一般稱之爲PP檔案，該檔案將appID，開發者證書，硬件Device綁定到一塊兒，在開發者中心配置好後可以添加到Xcode上，也可以直接在Xcode上連接開發者中心生成，真機調試時需要在PP檔案中添加真機的udid；是真機調試和必架必備之珍品；

平常我們的製作流程一般都是按以上序列進行，先利用開發者帳號登陸開發者中心，創建開發者證書，appID，在appID中開通推送服務，在開通推送服務的選項下面創建推送證書（服務器端的推送證書見下文），之後在PP檔案中綁定所有的證書id，添加調試真機等；

具體操作流程如下：

1、開發者證書的製作，首先登陸到開發者中心，找到證書配置的版塊，猛戳進入，點進證書，會顯示如下介面，點擊右上角的加號

會出現以下介面，該操作重複兩次，分別創建開發測試證書和發佈證書，開發測試證書用於真機調試，發佈證書用於提交到appStore，我們以開發測試證書爲例，選擇第一個紅框中的內容；

然後下一步，會提示創建CSR檔案，也就是證書籤名請求檔案，會有很詳細的操作說明，如果英文不太好，可以參考下圖；

之後將該CSR檔案儲存到一處；

備註：CSR檔案儘量每個證書都製作一次，將常用名稱區分開來，因爲該常用名稱是證書中的密鑰的名字；

之後在開發者中心將該CSR檔案提交；

提交上去後就會生成一個cer證書， 有效期爲一年；

利用同樣的方法配置一下Distribution發佈證書，下載儲存，雙擊安裝；在鑰題串登陸證書中可以檢視，其中專用密鑰的名字即爲CSR請求檔案中的常用名稱；

2、以上開發者證書的配置完成了，下面我們來配置appID和推送證書；在左邊欄中選擇appID，勾選右邊的push可選項，爲該appID所對應的應用添加推送功能，下面會看到創建證書的按鈕，分別爲開發證書和發佈證書，下面的流程就和上述1中創建證書一樣了，都是先建立證書請求檔案，然後提交生成就行了，需要注意的是，雖然在左邊欄證書欄中也可以直接創建推送證書，但是還是建議在appID中，勾選了push服務後在此處創建，這樣會避免因爲忘了開通push服務而導致推送不可用的情況發生；

證書創建完成後，下載儲存，雙擊安裝即可；

3、最後我們來進行PP檔案的製作

該流程進行兩次，分別創建開發測試用PP檔案和發佈PP檔案，前者用於真機測試，後者用於提交發布；Ad Hoc格式一般用於企業帳號，此處我們忽略；

選擇後提交

會自動檢測匹配appID，另外下拉項中還可以選擇wildCard格式，該格式爲自動生成，使用*通配符，適用於批量的，沒有推送，PassCard等服務的應用；我們選擇我們剛剛創建的appID，之後下一步選擇證書；

繼續，這裏有一個區別，因爲PP檔案的開發測試版需要真機調試，所以我們需要綁定真機，這裏因爲之前我添加過一些設備，所以這裏就可以直接全選添加，如果沒有的話，需要將真機的udid複製出來在此添加，在發佈PP檔案中，是沒有這一步的；

之後就是輸入一個PP檔案的名字了，然後生成，下載儲存，雙擊添加到Xcode庫中，這樣在真機調試或者發佈時，就可以分別有不同的PP檔案與其對應；