java實驗中用到的各種常用設計模式總結與歸納
在幾次java實驗之中，我們應用了大量的設計模式，下面我歸納了其中幾種非常常用的設計模式：
一． 工廠模式（Factory Pattern）
工廠模式是java程式設計中最為常用的幾種設計模式之一。這種類型的設計模式屬于建立型模式，它提供了一種建立對象的最佳方式。在工廠模式中，我們在建立對象時不會對用戶端暴露建立邏輯，并且是通過使用一個共同的接口來指向新建立的對象。在Lab3中，我們在建立多軌道系統的時候，就對于工廠模式有了即為成功的運用。
具體實作：
先定義抽象物品類的接口
然後是各種物品的具體實作
之後定義抽象工廠的接口
最後是各種具體工廠的實作，具體工廠裡産生各種具體物體
總結：
意圖：定義一個建立對象的接口，讓其子類自己決定執行個體化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。
主要解決：主要解決接口選擇的問題。
何時使用：我們明确地計劃不同條件下建立不同執行個體時。
如何解決：讓其子類實作工廠接口，傳回的也是一個抽象的産品。
關鍵代碼：建立過程在其子類執行。
優點： 1、一個調用者想建立一個對象，隻要知道其名稱就可以了。 2、擴充性高，如果想增加一個産品，隻要擴充一個工廠類就可以。 3、屏蔽産品的具體實作，調用者隻關心産品的接口。
缺點：每次增加一個産品時，都需要增加一個具體類和對象實作工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這并不是什麼好事。
注意事項：作為一種建立類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象适合使用工廠模式，而簡單對象，特别是隻需要通過 new 就可以完成建立的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。
二． 政策模式（Strategy Pattern）
在政策模式（Strategy Pattern）中，一個類的行為或其算法可以在運作時更改。這種類型的設計模式屬于行為型模式。在政策模式中，我們建立表示各種政策的對象和一個行為随着政策對象改變而改變的 context 對象（政策上下文）。政策對象改變 context 對象的執行算法。
在Lab3中TrackGame分組方法的實作以及Lab5中IO的選擇均使用到了政策模式，可見它在java程式設計中非常常用
具體實作：
先定義一個抽象政策接口
然後是各種政策的具體實作
之後建立政策上下文統一管理
最後是政策的調用
總結：
意圖：定義一系列的算法,把它們一個個封裝起來, 并且使它們可互相替換。
主要解決：在有多種算法相似的情況下，使用 if…else 所帶來的複雜和難以維護。
何時使用：一個系統有許多許多類，而區分它們的隻是他們直接的行為。
如何解決：将這些算法封裝成一個一個的類，任意地替換。
關鍵代碼：實作同一個接口。
優點： 1、算法可以自由切換。 2、避免使用多重條件判斷。 3、擴充性良好。
缺點： 1、政策類會增多。 2、所有政策類都需要對外暴露。
三． 原型模式（Prototype Pattern）
原型模式（Prototype Pattern）是用于建立重複的對象，同時又能保證性能。這種類型的設計模式屬于建立型模式，它提供了一種建立對象的最佳方式。這種模式是實作了一個原型接口，該接口用于建立目前對象的克隆。當直接建立對象的代價比較大時，則采用這種模式。例如，一個對象需要在一個高代價的資料庫操作之後被建立。我們可以緩存該對象，在下一個請求時傳回它的克隆，在需要的時候更新資料庫，以此來減少資料庫調用。
在Lab5中，我們成功使用了原型模式對于代碼進行優化，提高代碼的性能
具體實作：
比較常用的實作方式比較簡單，即為直接傳回父輩的克隆方法
總結：
意圖：用原型執行個體指定建立對象的種類，并且通過拷貝這些原型建立新的對象。
主要解決：在運作期建立和删除原型。
何時使用： 1、當一個系統應該獨立于它的産品建立，構成和表示時。 2、當要執行個體化的類是在運作時刻指定時，例如，通過動态裝載。 3、為了避免建立一個與産品類層次平行的工廠類層次時。 4、當一個類的執行個體隻能有幾個不同狀态組合中的一種時。建立相應數目的原型并克隆它們可能比每次用合适的狀态手工執行個體化該類更友善一些。
如何解決：利用已有的一個原型對象，快速地生成和原型對象一樣的執行個體。
關鍵代碼： 1、實作克隆操作，在 JAVA 繼承 Cloneable，重寫 clone()，在 .NET 中可以使用 Object 類的 MemberwiseClone() 方法來實作對象的淺拷貝或通過序列化的方式來實作深拷貝。 2、原型模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些"易變類"擁有穩定的接口。
優點： 1、性能提高。 2、逃避構造函數的限制。
缺點： 1、配備克隆方法需要對類的功能進行通盤考慮，這對于全新的類不是很難，但對于已有的類不一定很容易，特别當一個類引用不支援串行化的間接對象，或者引用含有循環結構的時候。 2、必須實作 Cloneable 接口。
心得與體會：
在六個Lab中，我們使用了大量的設計模式，其中有十分常用的，也有很冷門的。設計模式雖然在編寫的時候需要額外花時間去按照規定的模式編寫而不能随心所欲，但是也給我們的代碼帶來了極大的提升。我深刻了解到了這其中的便利。
在今後的java及其他代碼的編寫過程中，如果我們可以熟練掌握各種常用設計模式的使用，則不但可以提升我們程式代碼的及結構性，可讀性，友善别人了解，而且可以或多或少地提高我們程式的性能，優化時間空間複雜度。是以在之後的代碼編寫時，也要時刻記得學習設計模式，使用設計模式，升華設計模式。