設(shè)計模式の結(jié)構(gòu)類模式

結(jié)構(gòu)類模式更關(guān)注與代碼的結(jié)構(gòu)互例，通過多個類型的組合達(dá)成一個更復(fù)雜的結(jié)構(gòu)來提供一定的可擴(kuò)展焕窝、可維護(hù)性章喉。

適配器模式

適配器這個名詞已經(jīng)能夠說明該模式的結(jié)構(gòu)了缭乘。就像我們筆記本電腦的適配器一樣，將220V的交流電轉(zhuǎn)換成電腦能夠使用的低電壓直流電邑茄。

這個情況多發(fā)于多人協(xié)作或不同團(tuán)隊(duì)之間姨蝴。比如我寫了一個貝塞爾曲線的類，A同學(xué)覺得我這個貝塞爾曲線比他現(xiàn)在用的好用多了肺缕。但是如果使用了我寫的貝塞爾曲線類使得他要改好多處代碼左医，這樣修改起來累不說還容易出錯，最好的辦法就是創(chuàng)建一個適配器同木，將新的貝塞爾曲線包裝起來浮梢，使得它兼容舊的代碼。

public class BadassBezierCurve
{
    public void AddPivot(Vector3 vec){}
    
    public Vector3 GetVector(float t){}
}

public class SuckedBezierCurve
{
    public void AddPoint(Vector3 vec){}
    
    public Vector3 GetPointAt(float t){}
}

public class BadassBezierCurveWrapper
{
    private BadassBezierCurve curve;
    
    public void AddPoint(Vector3 vec)
    {
        curve.AddPivot(vec);
    }
    
    public Vector3 GetPointAt(float t)
    {
        curve.GetVector(t);
    }
}

用了適配器模式以后對比StartModified方法里的代碼,我們在StartAdapted的代碼只有第一行和OldStart是不一樣的.

public class SomeMonoBehaviour : MonoBehaviour
{
    private void OldStart()
    {
        var curve = GetComponent<SuckedBezierCurve>();
        curve.AddPoint(Vector3.zero);
        curve.AddPoint(Vector3.forward);
        curve.AddPoint(Vector3.up);
        Debug.Log(curve.GetPointAt(.5f));
    }
    
    private void StartAdapted()
    {
        var curve = GetComponent<BadassBezierCurve>();
        curve.AddPoint(Vector3.zero);
        curve.AddPoint(Vector3.forward);
        curve.AddPoint(Vector3.up);
        Debug.Log(curve.GetPointAt(.5f));
    }
    
    private void StartModified()
    {
        var curve = GetComponent<BadassBezierCurve>();
        curve.AddPivot(Vector3.zero);
        curve.AddPivot(Vector3.forward);
        curve.AddPivot(Vector3.up);
        Debug.Log(curve.GetVector(.5f));
    }
}

唉, 我以為適配器模式有多神奇,能讓我一行代碼都不用改呢,然而適配器模式表示不服.
想想一下,玩意這個BadassBezierCurve雖然很好用,但是有一個不易重現(xiàn)的bug迫使你不得不用回舊的貝塞爾曲線腳本,你會怎么做?

注釋掉新的代碼,把舊的代碼重新加回去?

private void StartModified()
    {
        //var curve = GetComponent<BadassBezierCurve>();
        var curve = GetComponent<SuckedBezierCurve>();
    }

接口在一旁冷笑道:"Naive!".

S.O.L.I.D.五大原則的"D"是什么原則,他的要求是什么?

我們可以這樣做:

public interface IBezierCurve
{
    void AddPoint(Vector3 vec);
    void GetPointAt(float t);
}

public class BadassBezierCurve : IBezierCurve
{
    //其余不變
}

public class SuckedBezierCurve : IBezierCurve
{
    //其余不變
}

//最終實(shí)現(xiàn)

public class SomeMonoBehaviour : MonoBehaviour
{
    private void Start()
    {
        var curve = GetComponent<IBezierCurve>();
        //其余不變
    }
}

那么最終不論GameObject上的是好的還是壞的貝塞爾曲線,代碼一律不用改變.DIP微微一笑深藏功與名.

橋接模式

有時候我們在編程的時候發(fā)現(xiàn)我們依賴的多個對象會根據(jù)環(huán)境進(jìn)行一定的變化彤路，如果我們要根據(jù)這幾個對象進(jìn)行一一適配可能要寫很多代碼秕硝。

比如：

public abstract class A { }
public class a1 : A { }
public class a2 : A { }

public class a1b1 : a1 { }
public class a2b1 : a2 { }

public class a1b2 : a1 { }
public class a2b2 : a1 { }

我們能看到上面b1的功能實(shí)現(xiàn)了兩次，分別是a1b1與a2b1洲尊，b2也是一樣远豺，這樣導(dǎo)致B類型的功能無法通過類的繼承傳下去，因?yàn)樗械念惗祭^承于A類型坞嘀，而C#語言是不支持多類型繼承的躯护。這只是兩個類型的組合而已。

這種情況就比較適合橋接模式丽涩，將A和B兩種類型用橋搭在一起棺滞，這樣就可以組合出所有可能的方案而不需要多寫代碼。當(dāng)然矢渊，此處也依舊發(fā)揮了DIP的作用：類的雙方應(yīng)該依賴于抽象检眯。

回到我之前寫的運(yùn)動會的跑步功能時，我不確定我應(yīng)該用哪種方式來定義一個跑道的路線昆淡，也不確定用什么方式讓奇奇沿著這個路線跑锰瘸，于是我就這樣創(chuàng)建了一個基礎(chǔ)的跑步類，讓路線和跟隨代碼分開昂灵，并且可以互相組合避凝。

public class TrackRunner
{
    public ICurve curve;
    public ICurveFollower follower;
    
    public void Awake()
    {
        curve = GetComponent<ICurve>();
        follower = GetComponent<ICuveFollower>();
        follower.Init(curve);
    }
    
    private void Update()
    {
        follower.DoFollow();
    }
}

public interface ICurve
{
    Vector3 GetPoint(float t);
}

public interface ICurveFollower
{
    void Init(ICurve curve);
    void DoFollow();
}

然后確定使用貝塞爾曲線，但是沒找到好用的插件眨补」芟鳎回到前面適配器的問題，我們現(xiàn)在有多個貝塞爾曲線的實(shí)現(xiàn)撑螺。另外在跟隨路線功能上含思，有使用Tween的方法跟隨曲線的，也有將曲線分為平均N個點(diǎn)連接而成的點(diǎn)的組合的路點(diǎn)模式。

于是我的代碼實(shí)現(xiàn)如下：

public class TweenCurveFollower : ICurveFollower { }

public class WaypointCurveFollower : ICurveFollower { }

那么我們在真正使用的時候我們根據(jù)我們的需求在場景中對應(yīng)的GameObject中添加對應(yīng)的ICurve和ICurveFollower對象即可含潘，代碼根本不需要改變饲做。

裝飾模式

裝飾模式就像給你的手機(jī)加上各種功能的外殼一樣,加上硅膠外殼可以增加手機(jī)防摔性能;套上外置鏡頭的外殼能夠大大改進(jìn)你手機(jī)的攝像功能..裝飾模式能夠給你的已有功能的代碼添加其它功能.

這聽起來有點(diǎn)像繼承,裝飾模式和繼承的差別在哪里?從我上面手機(jī)外殼的例子來說,我們不改變手機(jī)本質(zhì),我們只在手機(jī)的外部做文章;繼承則類似在手機(jī)內(nèi)部做工作,比如替換某些零件什么的,當(dāng)然也可以在手機(jī)外部添加功能.

但是裝飾模式的實(shí)現(xiàn)方式更為靈活,并且萬一一個類它是封裝類無法被繼承,那么只能使用裝飾模式了.

public abstract class PhoneBase
{
    public abstract void Call(string phoneNumber);
    public abstract void TextTo(string phoneNumber, string content);
}

public class PhoneDecorator : PhoneBase
{
    public PhoneDecorator(PhoneBase phone)
    {
        this.phone = phone;
    }
    
    private PhoneBase phone;
    
    public override void Call(string phoneNumber)
    {
        phone.Call(phoneNumber);
    }
    
    public override void TextTo(string phoneNumber, string content)
    {
        phone.TextTo(phoneNumber, content);
    }
}

我們創(chuàng)建了一個PhoneDecorator但是它是繼承PhoneBase類的,和上面的例子有沖突啊,一個手機(jī)硅膠后蓋怎么可以打電話發(fā)短信?那是因?yàn)槟憧绰┝艘稽c(diǎn):在PhoneDecorator類的構(gòu)造方法里面需要傳遞一個PhoneBase對象進(jìn)去,這兩者組合以后才成為一個完整的裝飾構(gòu)造,也就是說這個完整的裝飾構(gòu)造不是硅膠套,而是套了硅膠套的手機(jī).

現(xiàn)在我們身處CIA黑客辦公室,這里擺著幾種通過手機(jī)來監(jiān)聽當(dāng)事人的設(shè)備,他們分別是:

//電話內(nèi)容監(jiān)聽器
public class PhoneBug : PhoneDecorator
{
    public PhoneDecorator(PhoneBase phone)
        :base(phone) 
    {
        bug = new BugDevice();
    }
    
    private BugDevice bug;
    
    public override void Call(string phoneNumber)
    {
        bug.BeginRecord();
        base.Call(phoneNumber);
        bug.EndRecord();
    }
}

//短信轉(zhuǎn)發(fā)器
public class PhoneTextRedirector : PhoneDecorator
{
    public PhoneTextRedirector(PhoneBase phone)
        :base(phone) 
    {
        redirector = new TextRedirector();
    }
    
    private TextRedirector redirector;
    
    public override void TextTo(string phoneNumber, string content)
    {
        base.TextTo(phoneNumber, string content);
        redirector("CIA_HQ", "owner: xxx to " + phoneNumber +":\n" + content);
    }
}

//地理位置記錄器
public class PhoneGPSTracker : PhoneDecorator
{
    public PhoneGPSTracker(PhoneBase phone)
        :base(phone) 
    {
        gps = new GPSDevice();
    }
    
    private GPSDevice gps;
    
    public override void Call(string phoneNumber)
    {
        base.Call(phoneNumber);
        gps.RecordCurrentPosition();
    }
    
    public override void TextTo(string phoneNumber, string content)
    {
        base.TextTo(phoneNumber, string content);
        gps.RecordCurrentPosition();
    }
}

現(xiàn)在CIA要員進(jìn)入機(jī)場監(jiān)聽重要人員的手機(jī):

public class Person
{
    public string Name { get; set; }
    public PhoneBase Phone { get; set; }
}

public class Airport
{
    public void Entrance(IEnumerable<Person> people)
    {
        foreach(var p in people)
        {
            var phone = p.Phone;
            p.Phone = null;
            p.Phone = SecurityCheck(phone);
        }
    }
    
    private PhoneBase SecurityCheck(PhoneBase phone)
    {
        var r = Random.value;
        if(r<.33f)
            return new PhoneBug(phone);
        else if( r<.66f)
            return new PhoneTextRedirector(phone);
        else
            return new PhoneGPSTracker(phone);
    }
}

注意一下SecurityCheck方法的返回類型,也是PhoneBase,也就是說一個人將他的手機(jī)交出去以后經(jīng)過安檢以后還給他的還是一部手機(jī),只不過是被動了手腳的手機(jī),然而可以做到當(dāng)事人完全不知情.

外觀模式

外觀模式就是負(fù)責(zé)將一個特別復(fù)雜的子系統(tǒng)里的一些功能簡化并整合到一個表面類中去.就好像汽車的中控臺,能通過一個小小的屏幕知道汽車那些功能是開著的,那些地方有故障等等,甚至可以一鍵將車?yán)锏亩鄠€系統(tǒng)調(diào)節(jié)到一定的程度實(shí)現(xiàn)不同的駕駛體驗(yàn).

這樣做的好處是可以將一個復(fù)雜的系統(tǒng)通過外觀模式封裝起來,讓使用者不需要深入系統(tǒng)其中也能夠很好的使用這個系統(tǒng).

public class Car
{
    public SuspensionSystem suspension;
    public DriveSystem drive;
    public ElectricSystem electricDevices;
}

public class CarFacade
{
    public Car car;
    public void SetDriveMode(string driveMode)
    {
        if(driveMode == "comfort")
        {
            car.suspension.spring.flexibility = Flexibility.Soft;
            car.suspension.tube.flexibility = Flexibility.Soft;
            drive.transmission.gearChangingMode = GearChangingMode.Quick;
            drive.engine.oilConsumeRate = 0.5f;
            electricDevices.setParam("Start-Stop", true);
        }
        else if(driveMode == "sport")
        {
            car.suspension.spring.flexibility = Flexibility.Hard;
            car.suspension.tube.flexibility = Flexibility.Hard;
            drive.transmission.gearChangingMode = GearChangingMode.Slow;
            drive.engine.oilConsumeRate = 1.5f;
            electricDevices.setParam("Start-Stop", false);
        }
        else
        {
            car.suspension.spring.flexibility = Flexibility.Normal;
            car.suspension.tube.flexibility = Flexibility.Normal;
            drive.transmission.gearChangingMode = GearChangingMode.Normal;
            drive.engine.oilConsumeRate = 1f;
            electricDevices.setParam("Start-Stop", true);
        }
    }
}

以上我們通過一個簡簡單單的SetDriveMode即可調(diào)整整車懸掛系統(tǒng),傳動系統(tǒng),還有電子系統(tǒng)做到我們想要的駕駛模式.這就是外觀模式,非常簡單.

享元模式

享元模式的定義是這樣的，一個類型實(shí)例有一些內(nèi)容可以被重用遏弱，而且對這個類的實(shí)例數(shù)量非常高的時候我們可以用到這個模式盆均。在我看來就是一個對象池嘛。不了解對象池的同學(xué)可以上網(wǎng)搜索一下簡單的對象池的代碼研究一下,這里就不贅述了.

代理模式

我們程序員對代理這個名字肯定比較熟悉,經(jīng)常在訪問一些"無法訪問"的網(wǎng)站的時候會用到它,或者平時我們要去政府辦點(diǎn)事,會發(fā)現(xiàn)流程麻煩并且復(fù)雜,這時候就有"代辦"服務(wù),你給他一些錢,他幫你全部搞定.

我們在編碼過程中有時候也會遇到這種問題,在做某些事情代價比較大的時候,會使用這種代理模式.

項(xiàng)目雪糕工廠中有一個需求,有些道具是需要使用金幣購買的.所以需要購買的物品會有一個價格標(biāo)簽,而且還要判定玩家買不買得起,如果買不起需要顯示一個鎖的圖標(biāo)告訴玩家.

所以這個需求最終做起來是這樣的:我們創(chuàng)建了一個GameObject,里面包含了鎖還有價格標(biāo)簽的底圖和具體價格的文字.再寫了一個這樣的腳本:

public class Product : MonoBehaviour
{
    public string productName;
    
    public Text priceLabel;
    
    private void Start()
    {
        var price = StoreSystem.GetPrice(productName);
        priceLabel.Text = price.ToString();
    }
}

項(xiàng)目中有30個以上的道具.我們要每個道具都加上這個功能的話會導(dǎo)致一個問題,如果未來策劃說我要改這個功能的外觀表現(xiàn),那我們就要在這30多個道具預(yù)置體上改30多次,這肯定是不允許出現(xiàn)的.所以我們將上面的功能GameObject保存成獨(dú)立的預(yù)置體.然后再寫一個代理代碼:

public class ProductProxy : MonoBehaviour
{
    public string productName;
    
    private void Start()
    {
        var pf = Resources.Load<GameObject>("ProductPrefab");
        var go = Instantiate(pf);
        go.getComponent<Product>().productName = productName;
        go.transform.setParent(transform);
    }
}

這樣一來我們通過ProduProxy這個純腳本的代理生成了具體價格功能的GameObject.這樣我們杜絕了在外觀修改上的修改風(fēng)險.

而有些代理模式的結(jié)構(gòu)是這樣的:

public class SomeCostlyObject
{
    public int GetResult()
    {
        System.Threading.Thread.Sleep(2);
        return new Random().NextInt();
    }
}
public class SomeProxy
{
    private SomeCostlyObject obj;
    
    public void GetResult(Action<int> onComplete)
    {
        //開設(shè)新線程執(zhí)行obj.GetResult();
        //等待返回值以后執(zhí)行onComplete回調(diào)
    }
}

這個代理將一個非常耗時的同步操作改為移步操作,通過這個代理我們就可以節(jié)省很多時間了.

Q:有沒有發(fā)現(xiàn)適配器模式,橋接模式,裝飾模式,代理模式他們幾個都很像?他們的區(qū)別在哪?