一、上篇回顧

　　上篇我們主要講述了創(chuàng)建型模式中的最后一個(gè)模式-原型模式，我們主要講述了原型模式的幾類實(shí)現(xiàn)方案，和原型模式的應(yīng)用的場景和特點(diǎn)，原型模式適合在哪些場景下使用呢？我們先來回顧一下我們上篇講述的3個(gè)常用的場景。

　　1、我們在運(yùn)行態(tài)的時(shí)候，動(dòng)態(tài)的創(chuàng)建一個(gè)動(dòng)態(tài)類型的對象的時(shí)候，可能我們使用原型模式，可以動(dòng)態(tài)的創(chuàng)建指定類型的副本，這無疑是好的選擇，否    則如果通過我們前面講述的幾個(gè)創(chuàng)建型模式來實(shí)現(xiàn)的話，效率和代價(jià)上是非常大的。

　　2、有的時(shí)候我們需要對比一個(gè)對象在處理前和處理后進(jìn)行對象狀態(tài)的對比，對比是否處理后對象的狀態(tài)是否發(fā)生變化，或者是其他的要求。這個(gè)時(shí)候通過原型模式來克隆對象的副本，遠(yuǎn)比通過引入其他的Factory或者abstract Factory 來的有效和更容易實(shí)現(xiàn)。

　　3、如果我們發(fā)現(xiàn)有一類這樣的對象，這類對象通常來說比較簡單，并且這類對象之間的差別很有規(guī)律，并且這類對象數(shù)量一般有限，那么這個(gè)時(shí)候，我們通過原型模式來做的話，通過一個(gè)對象來復(fù)制創(chuàng)建其他類型的對象可能比通過引入其他的Factory或者abstract Factory 更容易實(shí)現(xiàn)，而且只需要對象本身提供一個(gè)Clone()方法即可。

　　4、有的時(shí)候我們的項(xiàng)目中有這樣的情況，我們是在別人的功能的基礎(chǔ)上進(jìn)行擴(kuò)展，我們有不能修改現(xiàn)有的程序，如果這個(gè)應(yīng)用程序是基于其他類型的創(chuàng)建型模式，那么如果我們在系統(tǒng)中新增一個(gè)類型的時(shí)候，我們需要修改統(tǒng)一的創(chuàng)建型模式中的代碼，不管是修改配置文件還是具體的功能代碼，無疑都是要修改的，那么如果我們通過原型模式的話，只需要在新增類型的對象內(nèi)部，提供一個(gè)克隆方法即可，完成新對象的創(chuàng)建。

　　通過上面的情況，那么我們也能大概看出來原型模式的有一個(gè)前提，就是必須是基于對象之上調(diào)用Clone()方法完成對象的復(fù)制，如果沒有創(chuàng)建這個(gè)對象的話，可能不能直接使用該方法。

　　我們也講述了，對于Clone()對象的時(shí)候，深復(fù)制和淺復(fù)制的情況，還包括通過序列化對象的形式來完成對象的深復(fù)制。

　　二、摘要

　　本文主要是講述結(jié)構(gòu)型模式中一個(gè)比較常用的模式-外觀模式，這個(gè)模式呢，有個(gè)最大的特點(diǎn)將細(xì)粒度的對象包裝成粗粒度的對象，應(yīng)用程序通訪問這個(gè)外觀對象，來完成細(xì)粒度對象的調(diào)用，外觀模式一般是分布式應(yīng)用和系統(tǒng)架構(gòu)中的應(yīng)用服務(wù)層的設(shè)計(jì)中常用的方式，并且一般結(jié)合外觀模式+DTO來完成服務(wù)層的設(shè)計(jì)，提供分布式應(yīng)用服務(wù)的高效服務(wù)，外觀模式我們可以這樣理解，我們通過外觀的包裝，使應(yīng)用程序只能看到外觀對象，而不會(huì)看到具體的細(xì)節(jié)對象，這樣無疑會(huì)降低應(yīng)用程序的復(fù)雜度，并且提高了程序的可維護(hù)性。本文將會(huì)從以下幾個(gè)方面進(jìn)行講述：

　　1、外觀模式的使用場景和特點(diǎn)

　　2、外觀模式的實(shí)現(xiàn)方案。

　　3、總結(jié)外觀模式。

　　我們這里先給出一個(gè)外觀模式的原理圖：

　　這是未使用外觀模式之前的情況，下面給出使用外觀模式后的情形：

　　通過外觀對象來組織細(xì)粒度的服務(wù)的調(diào)用，外觀對象提供給外部應(yīng)用程序以使用的服務(wù)，而具體的調(diào)用細(xì)粒度的過程則被外觀對象給封裝起來，當(dāng)然這個(gè)過程就是封裝變化的部分，而將變化的部分與應(yīng)用程序進(jìn)行隔離，無疑對程

序的易用性和可維護(hù)性都是很大的提高。

　　三、本文大綱

　　a、上篇回顧。

　　b、摘要。

　　c、本文大綱。

　　d、外觀模式的特點(diǎn)及使用場景。

　　e、外觀模式的實(shí)現(xiàn)方案。

　　f、外觀模式使用總結(jié)。

　　四、外觀模式的特點(diǎn)及使用場景

　　外觀模式的主要思想是將復(fù)雜的細(xì)粒度的對象服務(wù)包裝成簡單的易使用的粗粒度的功能服務(wù)，我們大家最容易理解和知道的外觀模式就是，使用的API接口的封裝，我們將第三方的API接口引入到我們的項(xiàng)目中的時(shí)候，我們需要對這些接口進(jìn)行包裝，將細(xì)粒度的具體調(diào)用過程進(jìn)行包裝成外觀類的形式，通過外觀類來進(jìn)行統(tǒng)一的調(diào)用。我們平時(shí)把一些常用的公共方法也可以簡易的稱之為外觀模式，我們將復(fù)雜的細(xì)粒度的功能，包裝成一個(gè)比較通用的簡易的的粗粒度的功能。我們來看看哪些場景下，我們使用外觀模式很適合呢？

      1、我們在使用第三方類庫或者API的時(shí)候，我們通過本地的API接口的封裝，來完成對第三方API接口的粗粒度外觀對象，通過這個(gè)外觀對象可以很容易的完成服務(wù)的調(diào)用。我們這里舉例說明吧，例如現(xiàn)在我有一個(gè)發(fā)送手機(jī)短信的API接口，是第三方提供給我的API接口，那么我如何包裝呢？下面給出對API封裝的相關(guān)代碼和說明：

public class MessageHelper
{
    private static readonly MessageHelper instance = new MessageHelper();

    #region API接口

    [DllImport("EUCPComm.dll", EntryPoint = "SendSMS")]  //即時(shí)發(fā)送
    private static extern int SendSMS(string sn, string mn, string ct, string priority);

    [DllImport("EUCPComm.dll", EntryPoint = "SendSMSEx")]  //即時(shí)發(fā)送(擴(kuò)展)
    private static extern int SendSMSEx(string sn, string mn, string ct, string addi, string priority);

    [DllImport("EUCPComm.dll", EntryPoint = "SendScheSMS")]  // 定時(shí)發(fā)送
    private static extern int SendScheSMS(string sn, string mn, string ct, string ti, string priority);

    #endregion

    #region 對上面的API包裝后的方法
    public int SendSMSEx1(string sn, string mn, string ct, string addi, string priority)
    {
        return SendSMSEx(sn, mn, ct, addi, priority);
    }
    public int SendSMS1(string sn, string mn, string ct, string priority)
    {
        return SendSMS(sn, mn, ct, priority);
    }
    public int SendScheSMS1(string sn, string mn, string ct, string ti, string priority)
    {
        return SendScheSMS(sn, mn, ct, ti, priority);
    }
 #endregion
}        

        

        
        
      
        
it知識(shí)庫：系統(tǒng)架構(gòu)技能之設(shè)計(jì)模式—外觀模式，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。