接下來的篇章中我們會開始介紹結構型設計模式(Structural Patterns)
結構型的設計模式主要是依據不同的使用情境將繼承關係(is-a)轉變成擁有關係(has-a)。
這樣的方式能讓物件(Object)間的關係變成一個鬆耦合的狀態，
透過這樣的方式讓系統能有更高的開發彈性。

適配器模式 Adapter Pattern

定義

將一個類別的介面，轉換成別一個介面以供客戶使用。

用途

在網上很多地方尋找對於這個設計模式的用途說明，都太過於文謅謅了，
所以這邊我給了一個比較通俗的用途說明。

給舊有的物件(Object)或類別(Class)一個新的運用情境

範例

假設公司中已有一套極為複雜的商品定價計算方式。

public class Commodity{
    //成本
    private double cost = 100;
    private double complex = 3;

    public int getPrice(){
        //計算商品定價
        int price = cost * complex;
        return price;
    }

}

突然某天某個貨源的進價上漲了，有部分商品需要調漲5%，這時候我們應該如何設計?

//用戶的使用的介面
public interface ICommodity{
    public double getPrice();
}

//最後實際使用的物件
public class NewCommodity{
    private Commodity commodity;
    
    public NewCommodity(Commodity commodity){
        this.commodity = commodity;
    }
   
   public double getPrice(){
       double price = commodity.getPrice() * 1.05;
       return price ;
   }

}

public static void main(){
    //建立兩個物件
    Commodity commodity1 = new Commodity();
    Commodity commodity2 = new Commodity(); //將要漲價的商品
    
    //建立 commodity2 漲價後的物件 
    ICommodity newcommodity = new NewCommodity(commodity2);
    
    //印出 商品1 的定價
    Console.WriteLine(commodity1.getPrice());
    //印出 商品2 的定價
    Console.WriteLine(commodity2.getPrice());
    //印出 商品2 的定價 (漲價後)
    Console.WriteLine(newcommodity.getPrice());
}

結語

有人可能會問修改getPrice()不是也能達到一樣的效果嗎?
確實，修改getPrice()能達到一樣的效果。
但是會對系統中所有呼叫getPrice()的地方都會造成影響。
而透過這樣的設計模式，
可以看到在滿足用戶新的需求的同時也能保證原本的功能不受影響。

適配器模式，通常都會在創建時將舊有的物件傳入當作內部屬性，
所以在設計上常常會將介面(interface)設計成抽象類別(abstract)。