java設計模式·面試準備。

  寫在前邊:這篇内容是自己學習《java設計模式與面試精解》學習筆記，裡邊涵蓋了自己的思考内容。不是摘錄。我把這個設計模式的内容都變成自己容易了解的内容來記錄，絕對不官方。這适合做初步的入門，想深入就去看有代碼的那種講解。

  先說一下為什麼要學習設計模式，我們在平常的代碼中，如果心中沒有一個系統的設計模式了解，很可能這樣，自己寫的代碼，自己再删掉，因為不具有擴充性，實作的太僵硬。即使現在不删，以後還是得删。設計模式沒有那麼高大上，總共23種設計模式，平常我們用的也就幾種，設計模式可以讓我們有更好的實作，根據不同的業務場景，選擇合适的設計模式，會讓我們更加高效的碼代碼。

如果我寫的内容不夠滿足你的學習，我個人推薦一個不錯的學習地方：

​​https://design-patterns.readthedocs.io/zh_CN/latest/​​

目錄

​​1. 個人學習套路​​

​​2.設計模式分類​​

​​3.創造型模式​​

​​4.結構型模式​​

​​5.行為型模式（11種）​​

1. 個人學習套路

   學習設計模式就是三個要素：幹了什麼；有什麼好處，怎麼做。

   宏觀的思想：使用設計模式是為了更好的實作解耦，最終目的是讓代碼更好的維護。

2.設計模式分類

• 創造型模式：就是為了建立對象。
• 結構型模式：就是如何設計代碼結構更加合理。
• 行為型模式：關注的是對象間的通信。出發點是如何讓對象可以更好的交換資料，保持松耦合。

3.創造型模式

 建立型模式又分：

• 工廠方法模式
• 抽象工廠模式
• 生成器模式
• 單例模式
• 原型模式

1. 工廠模式

• 做了什麼：靈活的建立對象。
• 有什麼好處：工廠模式和構造方法相關，目的在與運作時會根據不同的情況建立不同的對象，
• 怎麼做：定義一個接口，對接口有多個不同的實作類，定義一個工廠類，在工廠類中根據傳入不同的參數，來建立不同的對象，并傳回。
• 聯想：這個模式最典型的就是spring  IOC（控制反轉）的實作，spring就是通過配置檔案，使用工廠模式，通過從配置檔案中的不同的類全稱，傳入到工廠類中，再反射建立對象的。

    注： 對于了解學習的了解掉這裡就行了，想要更深入的學習我貼一個工廠模式的UML圖：

• 抽象工廠（Creator）角色：該角色是工廠方法模式的核心，與應用系統無關，任何在建立對象的工廠類必須實作這個接口。
• 具體工廠（Concrete Creator）角色：該角色實作了抽象工廠接口，含有與應用密切相關的邏輯，并且受到應用程式的調用以建立産品對象。
• 抽象産品（Product）角色：該角色負責定義産品的共性，實作對産品最抽象的定義。
• 具體産品（Concrete Product）角色：該角色實作抽象産品角色所聲明的接口，工廠方法模式所建立的每一個對象都是某個具體産品角色的執行個體。

到這裡為止，想更深度的學習，就自己再查資料把。

  2.抽象工廠模式

• 做了什麼：更加豐富的建立對象。（為什麼說是更廣泛的建立對象，下邊做解釋）
• 有什麼好處：相比工廠模式可以提供更加豐富的對象出來，這裡指的是對象的種類。工廠模式可以建立出帶來的是一個類的對象，抽象工廠模式目的是建立更多類的對象，屏蔽了這些具體類的建立方法，實際應用的類名不再讓用戶端知道，将用戶端與具體類解耦。
• 下邊看UML圖

3.生成器模式

• 做了什麼：操作對象。将簡單的對象一步一步的生成複雜的對象，最後将複雜的對象傳回。
• 優點：隐藏了産品類建構過程中的内部細節，各個生成器之間是獨立的。每個生成器都能逐漸的建立對象。
• 我是這樣了解生成器模式的，就是一個複雜問題拆解的過程，比方說我們想要一個房子對象，那麼房子對象是最終态，生成器模式，就是對象過程化，打地基，蓋房子，裝修，最後傳回房子，中間的每一個過程又是獨立的。
• 聯想：在API中，StringBuffer 和StringBuilder 就是生成器的執行個體。
• 聯想2：這和工廠模式有什麼差別，生成器模式是一點一點的建立對象，有目标形态，最終傳回這個目标形态的對象就結束了。工廠模式是選一個類型的對象出來。
• 再上一個UML圖

抽象建造者（Builder）角色：該角色用于規範産品的各個組成部分，并進行抽象，一般獨立于應用程式的邏輯。

具體建造者（Concrete Builder）角色：該角色實作抽象建造者中定義的所有方法，并且傳回一個組建好的産品執行個體。

産品（Product）角色：該角色是建造中的複雜對象，一個系統中會有多于一個的産品類，這些産品類并不一定有共同的接口，完全可以是不相關聯的。

導演者（Director）角色：該角色負責安排已有子產品的順序，然後告訴Builder開始建造。

4.單例模式（常用，常見的設計模式）

• 幹什麼：操作對象。
• 有什麼好處：保證使用的是統一的對象，避免程式中重複建立對象的問題。因為對象是要占用記憶體的，大量重複的對象會造成資源浪費。
• 怎麼做：私有化構造方法，靜态私有化對象。單例模式有線程安全的問題，這是我們不得不考慮的問題。這也是配合鎖一起問的設計模式。

手寫一個單例模式

//雙重同步鎖保證線程安全 ， 在第一次調用這個對象的時候才建立對象
public class Singleton {
  private static Singleton instance;
  private Singleton(){

  }
  public synchronized static  Singleton getInstance(){
    if(instance == null){
      synchronized (Singleton.class){
        if (instance == null) {
          instance = new Singleton();
        }
      }
    }
    return instance;
  }

//主動執行個體化單例模式，直接在類加載就建立對象
public class singleton{
     private static Singleton instance = new Singleton（）;
     private Singleton(){
    };
}      

• UML

5.原型模式

• 做了什麼：操作了對象
• 有什麼好處：原型模式是在記憶體二進制流的拷貝，要比直接new一個對象性能好，特别是在一個循環體内産生大量的對象時，原型模式可以更好地展現其優點 。
• 怎麼做：就就是以克隆的形式複制對象。這裡需要注意的一點，想要被克隆的那個對象的類應該實作了Cloneable接口，因為是淺克隆，是以我們還應該重寫clone（）方法。

• UML圖

4.結構型模式

 結構型模式用于指導我們完成代碼的結構部分，這樣的機構設計能夠讓代碼更加清晰和易于了解，提高整體的可維護性。

• 擴充卡設計模式
• 橋接模式
• 組合模式
• 裝飾器模式
• 門面模式
• 享元模式
• 代理模式

1.擴充卡設計模式

• 做了什麼：操作類
• 有什麼好處:幫助那些因接口不相容而無法一起工作的類，讓他們能一起工作。提高類的複用度。增加了類的透明性。擴充卡模式可以讓兩個沒有任何關系的類在一起運作。
• 擴充卡模式的應用場景：修改一個已經投産中的系統時，需要對系統進行擴充，此時使用一個已有的類，但這個類不符合系統中的接口，這時使用擴充卡模式是最合适的，它可以将不符合系統接口的類進行轉換，轉換成符合系統接口的、可以使用的類
• UML

• 目标（Target）角色：該角色定義要轉換成的目标接口。
• 源（Adaptee）角色：需要被轉換成目标角色的源角色。
• 擴充卡（Adapter）角色：該角色是擴充卡模式的核心，其職責是通過繼承或是類關聯的方式，将源角色轉換為目标角色。

2.橋接模式

• 做了什麼：将類的接口與接口實作互相解耦
• 比如一個電視接口，兩種不同品牌實作類，接口中有開操作，關操作，換台操作，但又做了一個要遙控器類，在遙控器類中添加 了對電視接口的引用，是以遙控器可以對電視進行換台操作，将遙控器類抽象，可以再擴充功能。
• 聯想：問擴充卡模式和橋接模式有什麼差別，擴充卡模式是為了讓兩個不相容的類一起工作，橋接模式通過兩個不同的類的繼承層次将抽象對象和實作類對象解耦
• UML

抽象化（Abstraction）角色：該角色抽象化給出的定義，并儲存一個對實作化對象的引用。

實作化（Implementor）角色：該角色給出實作化角色的接口，但不給出具體的實作。

修正抽象化（RefinedAbstraction）角色：該角色擴充抽象化角色，它引用實作化角色并對抽象化角色進行修正。

具體實作化（ConcreteImplementor）角色：該角色對實作化角色接口中的方法進行具體實作。

3.組合模式

• 簡單來說一組對象的集合，将對象組合成樹形結構以表示“部分—整體”的層次結構，使得使用者對單個對象群組合對象的使用具有一緻性
• 舉出組合模式的例子
• 比如檔案系統的結構
• UML圖

抽象構件（Component）角色：該角色定義參加組合對象的共有方法和屬性，規範一些預設的行為接口。

葉子構件（Leaf）角色：該角色是葉子對象，其下沒有其他的分支，定義出參加組合的原始對象的行為。

樹枝構件（Composite）角色：該角色代表參加組合的、其下有分支的樹枝對象，它的作用是将樹枝和葉子組合成一個樹形結構，并定義出管理子對象的方法，如add()、remove()等。

4.裝飾模式

• 幹了什麼：操作了對象。我們一般有繼續擴充類的功能的需求，而裝飾器模式可以修改和擴充執行個體的行為，增加某個對象的功能，而不必擴充類。
• 怎麼做：定義一個接口，為接口建立一個實作類，在建立一個包含類型屬性的抽象類，此類的構造函數将接口類型執行個體指派給該屬性，此類是裝飾器的基類，我們能夠根據需要擴充這個類并建立我們想要的具體的修飾類。
• 我個人是這樣了解的，實際上裝飾器類就是一個實作目标類的接口的抽象類，然後子類再繼續繼承裝飾器抽象類，擴充功能就是在子類中增加的。
• 聯想：裝飾器模式自愛javaAPI中有展現，比如BufferReader方法
• 問裝飾器模式和繼承有什麼差別：使用繼承我們可以實作裝飾器模式最終的結果，但是裝飾器模式是在運作時更改原有對象達到目的。好處在于靈活。
• UML圖

抽象構件（Component）角色：該角色用于規範需要裝飾的對象（原始對象）。

具體構件（Concrete Component）角色：該角色實作抽象構件接口，定義一個需要裝飾的原始類。

裝飾（Decorator）角色：該角色持有一個構件對象的執行個體，并定義一個與抽象構件接口一緻的接口。

具體裝飾（Concrete Decorator）角色：該角色負責對構件對象進行裝飾。

5.門面模式

• 幹了什麼：簡化了複雜系統的外部接口，将使用者與系統内部複雜的細節進行屏蔽，門面模式注重的是代碼的解耦，強調代碼抽象。
• 執行個體：JDBC接口
• 生活中的例子幫我們了解門面模式：比方說我們都知道汽車内部的構造很複雜，具體的工作細節很多，但是想要開車并不難。汽車的設計就在于給我們提供了一個鑰匙的接口，插上鑰匙，我們就能啟動車，而不需要了解汽車内部怎麼啟動的。
• 中介模式和門面模式的差別：中介模式的目的在于對互動對象間任意通信進行抽象，并要實作不屬于互動對象實作的功能，在中介模式中，對象要清楚中介者的存在，并借助中介者完成通信。而在門邊模式中，不需要子系統知道門面層的存在。
• 擴充卡模式和門面模式的差別：擴充卡模式是讓兩個現有接口一起工作，并不需要定義新的接口，門面模式需要定義一個新的接口。
• UML

外觀（Facade）角色：用戶端可以調用該角色的方法，該角色知曉相關子系統的功能和責任。正常情況下，本角色會将所有從用戶端發來的請求委派到相應的子系統去，即該角色沒有實際的業務邏輯，隻是一個委托類。

子系統（subsystem）角色：可以同時有一個或多個子系統，每一個子系統都不是一個單獨的類，而是一個類的集合。子系統不知道外觀角色的存在，對于子系統而言，外觀角色僅僅是另外一個用戶端而已。

6.代理模式

• 做了什麼：将複雜對象用簡單對象代理。
• 用于當我們需要一個簡單的對象代替一個複雜的對象的時候。如果建立大對象時間空間開銷都很大，我們可以選擇推遲大對象的建立，用簡單對象代替大對象去工作，直到必須建立的時候才去建立。
• 舉個例子：使用URL位址代替大的圖檔對象，之前的操作都發生在URL上，直到圖檔必須顯現出來的時候，才去建立這個大對象。
• 問代理模式和裝飾器模式有什麼不同：首先目的不同，裝飾器模式是為了增強對象的功能，而代理模式是一個為了避免系統大開銷，用一個小的對象代替一個大對象去工作。
• UML圖

抽象主題（Subject）角色：該角色是真實主題和代理主題的共同接口，以便在任何可以使用真實主題的地方都可以使用代理主題。

代理主題（Proxy Subject）角色：也叫做委托類、代理類，該角色負責控制對真實主題的引用，負責在需要的時候建立或删除真實主題對象，并且在真實主題角色處理完畢前後做預處理和善後處理工作。

真實主題（Real Subject）角色：該角色也叫做被委托角色、被代理角色，是業務邏輯的具體執行者。

7.享元模式

• 幹了什麼：減少相似對象的建立。
• 優點：大幅減少記憶體中對象的數量，降低程式記憶體的占用，提高性能
• UML

• 内部狀态是存儲在享元對象内部的、可以共享的資訊，并且不會随環境改變而改變。
• 外部狀态是随環境改變而改變且不可以共享的狀态。享元對象的外部狀态必須由用戶端儲存，并在享元對象被建立之後，在需要使用的時候再傳入到享元對象内部。
• 享元模式的角色： 抽象享元（Flyweight）角色：該角色對享元類進行抽象。
• 具體享元（ConcreteFlyweight）角色：該角色實作抽象享元定義的業務。
• 享元工廠（FlyweightFactory）角色：該角色就是構造一個池容器，負責建立和管理享元角色，并提供從池容器中獲得對象的方法，保證享元對象可以被系統适當的共享。
• 用戶端（Client）角色：該角色需要自行存儲所有享元對象的外部狀态。

5.行為型模式（11種）

  行為型模式關注的是對象互相通信，出發點是如何讓對象之間互動資料，保持松耦合。

   行為型模式又可以分為對象行為型模式和類行為模式。

• 職責鍊模式
• 指令模式
• 解釋器模式
• 疊代器模式
• 中介者模式
• 備忘錄模式
• 觀察者模式
• 狀态模式
• 政策模式
• 模闆模式
• 通路者模式

1.職責鍊模式

• 幹了什麼：發送端發送一個請求到對象鍊中，對象鍊處理這個請求，如果鍊中的對象不處理請求，就将請求發送給鍊中的下一個對象。
• 職責鍊的目的是通過特定的設計，對請求的發送者和接受者解耦。
• 聯想：最典型的就是java中的異常處理機制。 servlet過濾器。
• UML

抽象處理者（Handler）角色：該角色對請求進行抽象，并定義一個方法以設定和傳回對下一個處理者的引用。

具體處理者（Concrete Handler）角色：該角色接到請求後，可以選擇将請求處理掉，或者将請求傳給下一個處理者。由于具體處理者持有對下一個處理者的引用，是以，如果需要，具體處理者可以通路下一個處理者。

2.指令模式

• 幹了什麼：實作的是發送者和接受者之間完全解耦，發送者是調用者的對象，接收者是請求執行特定操作的對象。将一個請求封裝成一個對象，進而使用不同的請求把用戶端參數化，對請求排隊或者記錄請求日志，可以提供指令的撤銷和恢複功能。
• 優點：類間解耦。調用者角色與接收者角色之間沒有任何依賴關系，調用者實作功能時隻須調用Command中的execute()方法即可，不需要了解是哪個接收者執行。指令模式結合其他模式會更優秀。指令模式可以結合責任鍊模式，實作指令族解析任務，結合模闆方法模式，則可以減少Command子類的膨脹問題。
• 問指令模式和這職責鍊模式之間的差別是什麼：職責鍊模式中指令找對象，經過對象傳遞，指令模式會找到特定的對象。
• UML

指令（Command）角色：該角色聲明一個給所有具體指令類的抽象接口，定義需要執行的指令。

具體指令（Concrete Command）角色：該角色定義一個接收者和行為之間的弱耦合，實作指令方法，并調用接收者的相應作。

調用者（Invoker）角色：該角色負責調用指令對象執行請求。

接收者（Receive）角色：該角色負責具體實施和

3.解釋器模式

  使用範圍有限。不做介紹了。

4.疊代器模式

最常用的一種設計模式

• 做了什麼:允許對一組對象元素的周遊，之是以非常常用，是因為其能在不考慮存儲方式情況下而直接對各類型的資料進行疊代。提供一種方法通路一個容器對象中各個元素，而又不需暴露該對象的内部細節。
• 通常通路集合對象中的元素可以使用疊代器，疊代器使我們周遊，擷取和删除元素。
• 使用疊代器通路集合中的資料内容的步驟如下：調用Iterator（）擷取一個位于結合起點的疊代器。調用hasNext（）實作資料的循環通路，隻要hasNext方法傳回真，就循環下去。循環中，通過next方法擷取每一個節點。
• UML

抽象疊代器（Iterator）角色：該角色負責定義通路和周遊元素的接口。

具體疊代器（Concrete Iterator）角色：該角色實作Iterator接口，完成容器元素的周遊。

抽象聚集（Aggregate）角色：該角色提供建立疊代器角色的接口。

具體聚集（Concrete Aggregate）角色：該角色實作抽象聚集接口，建立出容納疊代器的對象。

5.中介模式

• 幹了什麼：用一個中介對象封裝一系列對象（同僚）的互動，中介者使各對象不需要顯式的互相作用，進而使其耦合松散，而且可以獨立的改變它們之間的互動。
• 優點：減少類間的依賴，将原有的一對多的依賴變成一對一的依賴，使得對象之間的關系更易維護和了解。 避免同僚對象之間的過度耦合，同僚類隻依賴于中介者，使同僚類更易被複用，中介類和同僚類可以相對獨立地演化。 中介者模式将對象的行為和協作抽象化，将對象在小尺度的行為上與其他對象的互相作用分開處理。
• UML

抽象中介者（Mediator）角色：該角色定義出同僚對象到中介者對象的統一接口，用于各同僚角色之間的通信。

具體中介者（Concrete Mediator）角色：該角色實作抽象中介者，它依賴于各個同僚角色，并通過協調各同僚角色實作協作行為。

抽象同僚（Colleague）角色：該角色定義出中介者到同僚對象的接口，同僚對象隻知道中介者而不知道其餘的同僚對象。

具體同僚（Concrete Colleague）角色：該角色實作抽象同僚類，每一個具體同僚類都清楚自己在小範圍内的行為，而不知道大範圍内的目的。

6.備忘錄模式

• 做了什麼：在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到原先儲存的狀态。
• 備忘錄模式有很多使用場景：提供一個可復原的操作。資料庫連接配接的事務管理使用的就是備忘錄模式。需要儲存和恢複資料的相關狀态場景。
• 備忘錄模式注意事項：備忘錄的生命周期，備忘錄建立出來就要在最近的代碼中使用，要主動管理它的生命周期，建立就要使用，不使用就要立刻删除其引用，等待垃圾回收器對它的回收處理。 備忘錄的性能。不要在頻繁建立備份的場景中使用備忘錄模式，例如for循環中，一是控制不了備忘錄建立的對象數量；二是大對象的建立是要消耗資源的。系統的性能需要考慮。是以，如果出現這樣的代碼，設計師應該修改架構。
• UML

發起人（Originator）角色：該角色記錄目前時刻的内部狀态，負責定義哪些屬于備份範圍的狀态，負責建立和恢複備忘資料。

備忘錄（Memento）角色：該角色負責存儲發起人角色的内部狀态，在需要時提供發起人需要的内部狀态資料。

負責人（Caretaker）角色：該角色對備忘錄角色進行管理、儲存和提供備忘錄。

7.觀察者模式

• 做了什麼：觀察者模式主要解決的是對象之間一對多的關系，當一個對象改變時，同時告訴多個關聯對象。定義對象間一種一對多的依賴關系，使得每當一個對象改變狀态，則所有依賴于它的對象都會得到通知并被自動更新。
• 優點:觀察者和被觀察者之間是抽象耦合。被觀察者角色所知道的隻是一個具體觀察者集合，每一個具體觀察者都符合一個抽象觀察者的接口。被觀察者并不認識任何一個具體的觀察者，它隻知道它們都有一個共同的接口。由于被觀察者和觀察者沒有緊密的耦合在一起，是以它們可以屬于不同的抽象化層次，且都非常容易擴充。
• UML

抽象主題（Subject）角色：該角色又稱為“被觀察者”，可以增加和删除觀察者對象。

抽象觀察者（Observer）角色：該角色為所有的具體觀察者定義一個接口，在得到主題的通知時更新自己。

具體主題（Concrete Subject）角色：該角色又稱為“具體被觀察者”，它将有關狀态存入具體觀察者對象，在具體主題的内部狀态改變時，給所有登記過的觀察者發出通知。

具體觀察者（Concrete Observer）角色：該角色實作抽象觀察者所要求的更新接口，以便使自身的狀态與主題的狀态相協調。

8.狀态模式

• 做了什麼：根據狀态的不同，而有不同的行為。
• UML

抽象狀态（State）角色：該角色用以封裝環境對象的一個特定的狀态所對應的行為。

具體狀态（Concrete State）角色：該角色實作環境的一個狀态所對應的行為。

環境（Context）角色：該角色定義用戶端需要的接口，并負責具體狀态的切換。它會保留一個具體狀态類的執行個體，該執行個體給出環境對象的現有狀态。

9.政策模式：

• 幹了啥：根據不同的情況選擇不同的計算政策。把行為抽象成接口，再通過組合的形式，展現出來的就是不一樣的。
• 怎麼用：比方說一個商場櫃台的結賬系統，根據不同的情況，商場可能會做活動，而打不同的折。這就需要不同的算法。這個時候使用政策模式就比較好。

UML

環境（Context）角色：該角色也叫上下文角色，起到承上啟下的作用，屏蔽高層子產品對政策、算法的直接通路，它持有一個Strategy類的引用。

抽象政策（Strategy）角色：該角色對政策、算法進行抽象，通常定義每個政策或算法必須具有的方法和屬性。

具體政策（Concrete Strategy）角色：該角色實作抽象政策中的具體操作，含有具體的算法。

10.模闆方法模式

• 做了啥：一個模闆方法定義算法的各個步驟，算法的一個步驟或若幹個步驟由子類通過重寫實作，同時保證了算法的完整性，又能實作不同的功能。
• 怎麼做：定義好算法流程，将過程中的某幾個方法抽象，丢給子類去實作。
• UML

抽象模闆（Abstract Template）角色：該角色定義一個或多個抽象操作，以便讓子類實作；這些抽象操作是基本操作，是一個頂級邏輯的組成步驟。還需要定義并實作一個或幾個模闆方法，這些模闆方法一般是具體方法，即一個架構，實作對基本方法的排程，完成固定的邏輯。

具體模闆（Concrete Template）角色：該角色實作抽象模闆中定義的一個或多個抽象方法，每一個抽象模闆角色都可以有任意多個具體模闆角色與之對應，而每一個具體模闆角色都可以給出這些抽象方法的不同實作，進而使得頂級邏輯的實作各不相同。

11.通路者模式

• 做了啥：用簡化對象相關操作的分組，這些操作由通路者來執行，而不是放在通路者的類中。封裝一些作用于某種資料結構中的各元素的操作，它可以在不改變資料結構的前提下定義作用于這些元素的新的操作。
• 優點：通路者模式使得增加新的操作變得很容易，增加新的操作隻需增加新的通路者類。
• 通路者模式将有關的行為集中到一個通路者對象中，而不是分散到一個個元素類中
• 累積狀态。每一個單獨的通路者對象都集中了相關的行為，進而也就可以在通路的過程中将執行操作的狀态積累在自己内部，而不是分散到很多的元素對象中，益于系統的維護。
• UML

抽象通路者（Visitor）角色：該角色聲明一個或多個通路操作，定義通路者可以通路哪些元素。

具體通路者（Concrete Visitor）角色：該角色實作抽象通路者角色中的各個通路操作。 抽象元素（Element）角色：該角色聲明一個接受操作，接受一個通路者對象。

具體元素（Concrete Element）角色：該角色實作抽象元素中的接受操作。

結構對象（Object Structure）角色：該角色有以下責任，可以周遊結構中的所有元素；如果需要，提供一個高層次的接口讓通路者對象可以通路每一個元素，也可以設計一個複合對象或者一個集合，如List或Set。