推薦：解讀 .NET開(kāi)發(fā)者常犯的錯(cuò)誤
.NET開(kāi)發(fā)過(guò)程中不是程式的無(wú)法運(yùn)行，就是程式的效率慢的同蝸牛在爬; 這種情況在.NET的新手中尤其常見(jiàn)；我不知道為什么，一些介紹.NET開(kāi)發(fā)的書(shū)本里引用的例子代碼，也對(duì)此問(wèn)題視而不見(jiàn)，尤其讓我郁悶的是一些我喜歡的書(shū)也出現(xiàn)了同樣的問(wèn)題。 這篇文章不僅對(duì).N

意圖

把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本接口不匹配而無(wú)法在一起工作的兩個(gè)類能夠在一起工作。

場(chǎng)景

假設(shè)網(wǎng)絡(luò)游戲的客戶端程序分兩部分。一部分是和服務(wù)端通訊的大廳部分，大廳部分提供的功能有道具購(gòu)買(mǎi)、讀取房間列表、創(chuàng)建房間以及啟動(dòng)游戲程 序。另一部分就是游戲程序了，游戲程序和大廳程序雖然屬于一個(gè)客戶端，但是由不同的公司在進(jìn)行開(kāi)發(fā)。游戲大廳通過(guò)實(shí)現(xiàn)約定的接口和游戲程序進(jìn)行通訊。

一開(kāi)始的設(shè)計(jì)就是，大廳程序是基于接口方式調(diào)用游戲程序啟動(dòng)游戲場(chǎng)景方法的。在大廳程序開(kāi)發(fā)接近完成的時(shí)候，公司決定和另外一家游戲公司合作， 因此希望把大廳程序能適用另一個(gè)游戲。而這個(gè)新游戲的遵循的是另一套接口。是不是可以避免修改原先調(diào)用方法來(lái)啟動(dòng)場(chǎng)景呢？或許你會(huì)說(shuō)，既然只有一個(gè)方法修 改，那么修改一下也無(wú)妨，我們假設(shè)大廳程序和游戲程序之間有100個(gè)接口，其中的大部分都有修改呢？因?yàn)橛螒虺绦蚪涌诘男薷�，大廳程序可能要修改不止 100個(gè)地方。這樣接口的意義何在呢？

此時(shí)可以考慮使用Adapter模式來(lái)適配這種接口的不匹配情況。

using System;

using System.Collections.Generic;

using System.Text;

namespace AdapterExample

{

class Program

{

static void Main(string[] args)

{

Lobby lobby = new Lobby();

lobby.CreateRoom("HalfPaper");

lobby.StartGame();

}

}

interface IGame

{

void StartScene(string sceneName);

void EnterPlayer(string playerName);

}

class Lobby

{

private string sceneName;

public void CreateRoom(string sceneName)

{

this.sceneName = sceneName;

}

public void StartGame()

{

IGame game = new GameAdapter();

game.StartScene(sceneName);

game.EnterPlayer("yzhu");

}

}

class Game

{

public void LoadScene(string sceneName, string token)

{

if (token == "Abcd1234")

Console.WriteLine("Loading " + sceneName + "...");

else

Console.WriteLine("Invalid token!");

}

public void EnterPlayer(int playerID)

{

Console.WriteLine("player:" + playerID + " entered");

}

}

class GameAdapter : IGame

{

private Game game = new Game();

public void StartScene(string sceneName)

{

game.LoadScene(sceneName, "Abcd1234");

}

public void EnterPlayer(string playerName)

{

game.EnterPlayer(GetPlayerIDByPlayerName(playerName));

}

private int GetPlayerIDByPlayerName(string playerName)

{

return 12345;

}

}

}

 

 

可以看到，原先的接口中，啟動(dòng)游戲場(chǎng)景只需要一個(gè)參數(shù)，就是游戲場(chǎng)景名，而進(jìn)入新的玩家需要提供玩家ID(新游戲都使用玩家ID而不使用玩家賬戶名)。

IGame接口就是適配器模式中的目標(biāo)角色，這是客戶所期待的接口。也是針對(duì)老的游戲程序所遵循的接口。

 

Lobby類相當(dāng)于調(diào)用方或者客戶，它原先的代碼可能是如下的：

 

Game game = new Game();

 

 

但是由于接口的改變，現(xiàn)在不能直接實(shí)例化游戲類，只能實(shí)例化適配器類型。雖然還是需要改動(dòng)，但是這個(gè)改動(dòng)是很小的，而且完全可以通過(guò)用動(dòng)態(tài)加載程序集來(lái)消除這種改動(dòng)。

 

GameAdapter類是適配器角色，它是適配器模式的核心，用于把源接口轉(zhuǎn)變?yōu)槟繕?biāo)接口。在這里，我們看到，它實(shí)現(xiàn)目標(biāo)接口。

 

Game類型是源角色，或者說(shuō)是需要適配的對(duì)象。或許它也遵循了另外一套接口，不過(guò)我們不是很關(guān)心這個(gè)，因此代碼中也沒(méi)有體現(xiàn)。

 

使用了適配器模式后，客戶端代碼沒(méi)有做什么修改。客戶端代碼老老實(shí)實(shí)的依賴接口，它并沒(méi)有錯(cuò)，如果因此依賴對(duì)象的修改而需要大幅度修改就很無(wú)辜 了，我們?cè)谶m配器中把本來(lái)沒(méi)有關(guān)聯(lián)的兩個(gè)接口適配在了一起。我們可以看到，適配器做的不僅僅是換一換方法名，如果源角色和目標(biāo)角色的差異非常大，那么適配 器需要做很多工作。

 

何時(shí)采用

 

從代碼角度來(lái)說(shuō)， 如果你希望分離復(fù)雜類型構(gòu)建規(guī)則和類型內(nèi)部組成，或者希望把相同的構(gòu)建過(guò)程用于構(gòu)建不同類型的時(shí)候可以考慮使用建造者模式。

 

從應(yīng)用角度來(lái)說(shuō)， 如果你希望解耦產(chǎn)品的創(chuàng)建過(guò)程和產(chǎn)品的具體配件，或者你希望為所有產(chǎn)品的創(chuàng)建復(fù)用一套穩(wěn)定并且復(fù)雜的邏輯的時(shí)候可以考慮使用建造者模式。

 

實(shí)現(xiàn)要點(diǎn)

 

適配器模式是否能成功運(yùn)用的關(guān)鍵在于代碼本身是否是基于接口編程的，如果不是的話，那么適配器無(wú)能為力。

 

適配器模式的實(shí)現(xiàn)很簡(jiǎn)單，基本的思想就是適配器一定是遵循目標(biāo)接口的。

 

適配器模式的變化比較多，可以通過(guò)繼承和組合方式進(jìn)行適配，適配器可以是一組適配器產(chǎn)品，適配器也可以是抽象類型。

 

適配器模式和Facade的區(qū)別是，前者是遵循接口的，后者可以是不遵循接口的，比較靈活。

 

適配器模式和Proxy的區(qū)別是，前者是為對(duì)象提供不同的接口，或者為對(duì)象提供相同接口，并且前者有一點(diǎn)后補(bǔ)的味道，后者是在設(shè)計(jì)時(shí)就會(huì)運(yùn)用的。

 

注意事項(xiàng)

 

在對(duì)兩個(gè)無(wú)關(guān)類進(jìn)行適配的時(shí)候考慮一下適配的代價(jià)，一個(gè)非常龐大的適配器可能會(huì)對(duì)系統(tǒng)性能有影響。

 

 

分享：談對(duì)程序開(kāi)發(fā)中異常的處理
從接觸異常開(kāi)始我就弄不明白她，不會(huì)用她，想在系統(tǒng)中是異常機(jī)制發(fā)揮的淋漓盡致，進(jìn)行了很多嘗試，利用異常控制程序流程，利用異常做數(shù)字的判斷函數(shù)，利用異常消除系統(tǒng)中可能出現(xiàn)的惱人的異常提示框，為了更好了利用異常看了很多關(guān)于異常的文章，直到有一天