[軟件構造] 07 軟件構造lab3心得體會
每年哈工大軟件構造課的lab3都是重中之重，難度和任務量都相當的大，主要體現在設計方案的多樣性和自由選擇性，多種設計模式的應用，繁雜的單元測試等等。但自己真正認真完成下來收穫還是巨大的，不僅能夠對不同設計模式進行實踐，還能夠體驗到軟件構造中的可複用性和可維護性的重要性。
軟件構造lab3心得體會
1. 實驗任務簡述
實驗3要求設計並實現一個抽象數據類型Planning Entry，對現實中各類利用特定資源、在特定地點/位置開展的一項任務進行抽象，並在五個具體應用中使用它。
實驗要求需要完成的應用爲：1 必做、2 和 3 任選 1 個、4 和 5 任選 1 個。也就是說，至少要完成 3 個應用：1 and (2 or 3) and (4 or 5)。
- 航班管理
- 高鐵車次管理
- 操作系統進程管理
- 大學課表管理
- 學習日程管理
整個Planning Entry的設計都是圍繞這下面的這一張表來進行的。
2. Planning Entry的設計方案
實驗指導書上給出了較爲詳細的6種實現方案。方案一、二、三的缺點顯而易見，故可選的方案實際只有3種。方案四通過繼承樹實現多維度上的不同取值的方案，僅在五個維度上就會產生組合爆炸的情況，而在將來可能增加不同的維度和變化的情況下，會出現很差的可維護性和可複用性。
而對於方案六使用decorator設計模式，我在博客中對這種設計模式的結構和適用情況進行了詳細的分析。因此認爲強行使用這種設計模式並不合適。
綜上所述，我認爲方案五是實現PlanningEntry類及其子類型的一個比較好的方法，既保證了可複用性和可維護性，又一定程度上地避免了代碼重複，而且實現起來相對簡單。
方案五：CRP(Composite Reuse Principle)，通過接口組合及delegation委託實現局部共性特徵的複用。
以FlightEntry爲例，我設計的實現方案的UML類圖如下圖所示，另外還需要設計TrainEntry和CourseEntry，實現方案與FlightEntry類似。
3.實驗中用到的設計模式
實驗中涉及到的設計模式有Decorator,Facade,Iterator,State,Factory Method,Strategy這六種設計模式，而在這門課程中講述的設計模式總共有十三種，我打算在下一篇博客中對課程涉及到的這十三中設計模式進行一個總結，同時也方便自己的複習。(雖然也不知道什麼時候開學和期末考試😂)
Factory Method
通過在PlanningEntryFactory類中設立創建接口，然後在它的每個子類型中定義具體要創建哪一個實體的產品類。對應於三個不同的應用，分別有三個子類型的工廠分別創建出三個不同的計劃項，避免了通過new的方式實例化具體的PlanningEntry的子類型。這樣在類需要擴展時，只需要修改具體的工廠類中的創建方法，將變化的部分和不變的部分分隔開來，避免了客戶端的改變，提高了可維護性。
Iterator
這個設計模式的使用主要是用來以統一的方式遍歷Board類中的計劃項集合，可以看作是策略模式在遍歷訪問對象中的應用，爲了實現簡單，我並沒有自己寫遍歷的代碼，而是通過委託給List的Iterator，讓它來實現遍歷，我猜測老師的目的應該主要是讓我們能夠熟練的掌握各種設計模式的結構和應用。
Strategy
對於之前的API設計中的checkLocationConflict方法，我採用策略模式進行實現，對檢測位置獨佔衝突採用了兩種不同的算法，一種算法正是前面所說的分別選定每個計劃項，從前往後進行衝突檢測，而我實現另一種算法則是從後往前不斷進行檢測。這樣客戶端在調用時就可以根據不同的性能和實現要求選擇不同的算法。但在我的這個策略模式中的兩種策略其實本質區別並不大，因而主要是爲了練習策略設計模式，通過實驗對它進一步熟悉和理解。
4.正則表達式的運用
正則表達式的練習使用也是lab3實驗的一個比較有趣的地方，通過對給定的配置文件的信息進行解析，在app中實現從外部文件讀取數據。
正則表達式在計算機的各個方面應用真的非常廣泛。就拿這學期的課程來說，《形式語言與自動機》通過從理論的方面來研究正則表達式的結構，性質和設計等，而《軟件構造》通過從Java中的正則表達式應用來通過代碼進行使用，這兩門課程分別從理論和實踐的角度對它進行了介紹和使用，做到了理論與實踐有機結合，將理論付諸於實踐。
其中要求解析一條航班計劃項的文件格式如下所示。
Flight:2020-01-16,AA018
{
DepartureAirport:Hongkong
ArrivalAirport:Shenyang
DepatureTime:2020-01-16 22:40
ArrivalTime:2020-01-17 03:51
Plane:B6967
{
Type:A340
Seats:332
Age:23.7
}
}
這是我書寫的正則表達式的代碼，
String[] strings= {
"Flight:(?<date>\\d{4}-\\d{2}-\\d{2}),(?<name>[A-Z]{2}\\d{2,4})"
, "\\{"
, "DepartureAirport:(?<DepartureAirport>\\w+)"
, "ArrivalAirport:(?<ArrivalAirport>\\w+)"
, "DepatureTime:(?<DepartureTime>\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2})"
, "ArrivalTime:(?<ArrivalTime>\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2})"
, "Plane:(?<number>(N|B)\\d{4})"
, "\\{"
, "Type:(?<type>[a-zA-Z0-9]+)"
, "Seats:(?<seats>\\d{2,3})"
, "Age:(?<age>(\\d|[1-9]\\d)(.\\d)?)"
, "\\}"
, "\\}"};
5.寫在最後
lab3實驗給定的時間是五週，而在實驗中用到的課程知識也都是在這五週之內逐漸講授的，因而就會出現實驗要編寫的代碼依賴於還沒有講述到的課程，這種情況極大地提高了自學能力。😭例如：lab3的中前期需要應用到State設計模式來設計狀態，但是該設計模式卻是在實驗週期中的第4周纔講述到的，因而想要完成實驗只能夠儘可能早地去自學，否則的話在設計三個app，board的GUI設計，和各種單元測試的這三個硬核的近兩千行的代碼的壓力下根本不可能完成。
CSDN上有大佬好像在實驗發佈的第一週內就完成了lab3的實驗和驗收，還有的大佬app的設計採用的是GUI設計（近5000行代碼,相當華麗），而像我這樣的菜雞也只能夠將Board設計成GUI，而app採用命令行的方式來進行實現。這些都讓我深深地感慨到"路漫漫而修遠兮，吾將上下而求索"，自己和大佬之間的差距還是巨大的，還需要不斷的努力。