前言

這是大學時候上設計模式這門課寫的程序，當時課程任務是要求結合五個設計模式寫一個系統，最近偶然翻到，把系統分享一下。

成品預覽

主界面

?

功能介紹

訂單管理系統，實現了對訂單的增刪改查。且實現了將訂單內容寫入文件，每次增刪改查都會做保存，下次重啟程序時會自動加載之前已存入的訂單，簡單采用txt存文件到本地。

功能描述：

（1） 增加訂單功能：能對不同商品組合實現實時計算價格，并且根據用戶的身份產生vip用戶價格和普通用戶價格，并在訂單添加到已有的訂單列表中。并且內置了商品菜單，點擊商品菜單按鈕可以顯示詳細的商品菜單。 如果未確認選擇先提交訂單，會提示“訂單為空，無法提交”。 如果未確認選擇而單擊撤回選擇，會提示“訂單為空無法撤回”。 如果未選擇客戶類型便進行確認選擇，會提示“未選擇客戶類型”。

（2) 查找訂單功能：輸入訂單號實現對訂單查詢操作。能實現對訂單號格式的校驗，只能是數字格式，并且非空，若格式錯誤會彈窗提示，當訂單不存在時候也會彈出錯誤提示。

（3） 刪除訂單功能：輸入要刪除的訂單號，完成對訂單的刪除。并且可以撤回刪除操作。當想恢復上一次刪除的內容時，單擊撤回刪除按鈕即可實現。能實現對訂單號格式的校驗，只能是數字格式，并且非空，若格式錯誤會彈窗提示，當訂單不存在時候也會彈出錯誤提示

（4） 修改功能：使用了JTable,直接雙擊表格文本框即可完成修改和保存。

使用的設計模式

裝飾者模式

在增加新訂單中，對訂單的計價和描述使用了裝飾者模式。原先沒有裝飾者模式，則需要對每種組合都定義一個類，在類中設置其相關的價格和描述屬性，將會使得類的數量龐大。應用該模式后，可以大大減少類的數量。 使用裝飾者模式。有咖啡和茶兩種飲品，都繼承自一個抽象類Drink。配料有糖分，牛奶，豆漿三種配料，將配料作為decorator裝飾飲品，繼承自decorator，同時decorator又繼承自Drink類。使用裝飾模式，可以動態的給對象添加額外的功能，即包裝原有的類。這樣子，一個飲品添加多個配料，實現對飲品對象的多次包裝，每次包裝都后都能保存對象原有的功能屬性。這種情況下，無需增加不同組合的類，即可完成對每個組合的商品描述和計價。

UML圖：

組合模式

在增加新訂單功能中，有顯示商品菜單選項。對商品菜單的展示則應用了組合模式。如果菜單沒有使用組合模式，將不能很好的實現管理操作，如對菜單的一級目錄，二級目錄，三級目錄……的添加，刪除，遍歷。 應用組合模式，在該系統中，一級目錄對應飲品（Drinks類），二級目錄對應咖啡，茶，配料（DrinkTypes），三級目錄(SpecificTypes)是二級目錄各飲品的詳細種類。將菜單的一級目錄，二級目錄，三級目錄看成是組織結構，將他們的關系看成樹形結構，這樣子利于實現管理操作。能通過add的操作，向現有的菜單中添加新的目錄選項，或者通過remove操作，刪除對應目錄下不需要的內容。

UML圖：

備忘錄模式

撤銷刪除功能，應用到了備忘錄模式。沒有使用備忘錄模式前，備份刪除前的狀態需要new一個新的對象，并把需要備份的數據存到對象中，這暴露了對象內部的細節，如果需要備份的對象很多，這將不利于管理，開銷也會變大。 備忘錄模式能在不破壞封裝性前提下，捕獲對象的狀態，在對象之外保存這個狀態，并可用于恢復保存的狀態。在訂單管理下，Memento為訂單orderList的備份類，careTaker用于維護以Memento為元素的List。當有訂單被刪除時，刪除前的orderlist的狀態就會被保存到careTaker的MementoList中。這時，選擇撤銷的話careTaker就會從List中選取上次備份的內容，完成撤回操作。

UML圖：

代理模式

對vip用戶和普通用戶的區別計價，用到了代理模式。使用代理模式，對訂單的總價格RealPrice類，提供一種代理以控制對這個對象的訪問。RealPrice類（被代理類）和Proxy類（代理類)都實現同一個接口ProductPrice,在Proxy類實現實際業務邏輯，在該代理類的控制下，普通客戶訪問將得到原價價格，vip客戶訪問將得到八八折的價格。代理模式在一定程度上降低了耦合度，且如果對代理類做修改，則無需對被代理類進行改動，使得系統具有良好的靈活性和可擴展性，比如想新增一種客戶類型，則直接更改代理類即可。

UML圖：

單例模式

在圖形界面中，對查看所有訂單界面（GuiMain類）和增加新訂單界面（GuiAdd類）會來回切換，若不使用單例模式，每次切換都要new一個新的界面對象，頻繁的進行創建對象，耗費資源。 而使用單例模式，可以保證該類中只存在一個這樣的對象，確保只有單個對象被創建，節省了系統資源，可以提高系統的性能。在單例模式下，查看所有訂單界面（GuiMain類）和新增新訂單界面（GuiAdd類）都是通過使用getInstance函數創建唯一的實例，解決了耗費資源的情況。

UML圖：

使用

打開IDEA，運行main包中的MainTest啟動程序

進入程序主界面，載入已保存的訂單

增加新訂單：

返回主界面，在最后一行能找到新增的訂單

查看商品菜單

未選擇客戶類型時候：

未確認選擇情況下撤回選擇

未確認選擇情況下提交訂單

存在未提交訂單情況下點擊確認選擇：

查找訂單：

訂單號不存在，或者訂單格式有問題：

刪除訂單：

訂單號不存在，或者訂單格式有問題：

撤回刪除： 執行撤回前：

執行撤回后：

不存在刪除操作時：

修改訂單：單擊修改訂單顯示

直接在表格上即可進行修改，修改將自動保存

遇到的問題

在程序調試時，遇到一個大問題，無法讓顯示訂單的表格實時更新內容 。使用JAVA圖形界面，想實現對所有訂單在同一個界面顯示，并且要其支持修改和保存。這種情況下用JTable可以來實現所有訂單的顯示。但用了JTable后，卻發現訂單的新增，刪除，表格都不會刷新新數據，在此嘗試了好多種辦法解決。在經過長時間的鉆研下，發現借助DefaultTableModel對象可以實現，之后再使用Vector數組存儲表格每行每列的數據，調用setDataVector方法為DefaultTableModel對象存值。每次新增，刪除訂單都重復上述操作，使得表格內的內容能被實時更新。

合理運用設計模式，無疑是可以簡化類的數量，簡化不必要的代碼，使系統代碼可讀性更高，更簡潔，且可以優化系統的性能。如對單例模式的應用，能使對象不會被重復new出來，節約系統資源。再如裝飾者模式可以大幅度減少類的數量，使用decorator對特定對象添加功能，即可實現不同組合。合理運用設計模式，是可以減少類之間的耦合性，并使得系統的擴展性得到提高。

鏈接

scottyzh/MilkTea-Order-System: 奶茶訂單生成系統，使用多種設計模式 (github.com)

總結

以上是生活随笔為你收集整理的Java五种设计模式实现奶茶订单生成系统小DEMO的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。