BUAA OO 第4單元總結
阿新 • • 發佈：2021-06-26
一、本單元架構設計
如類圖所示，各個類之間的關係一目瞭然，類與類之間幾乎是完全模仿mdj檔案的樹形結構，層次化設計。官方包中已有的Umlxxx類，僅作為Myxxx類的成員變量出現。
各個Myxxx類中，除存有Umlxxx類、下級Myxxx類物件和相關的資料結構外，僅包含該類對應元素自身的查詢方法，不存也不訪問其他的、同級Myxxx物件。比如MyClass物件不能訪問其他MyClass、MyInterface等類的物件。
頂層MyUmlGeneralInteraction類負責構造類之間的樹形關係，實現官方介面中的抽象方法，只負責各個查詢方法中較為巨集觀的部分，負責協調多個同級Myxxx類間的查詢。比如getClassAttributeType
MyClass物件（獲得父類id也是靠MyClass中的getParentId方法，因只有頂層類存有所有MyClass的總表），並檢查型別的正確性。對每個Class中的查詢邏輯則在MyClass類中。
如此設計的優點在於，各個元素模型之間關係十分清晰，使得查詢邏輯有效分散與解耦，易於實現正確性檢驗。
缺點在於
- 構建類之間的樹形關係十分麻煩，若mdj檔案出現樹形結構上的改變，則程式碼修改起來也較為困難。
- 頂級類的邏輯較為複雜，該類中儲存了所有
Myxxx類物件的引用，且存在MyXXX類物件引用儲存了兩遍的情況，比如MyOperation類的物件引用在MyClass和MyUmlGeneralInteraction頂級類中都有。 - 在原本的mdj檔案的
Class元素中，Association、Attribute、Operation等應該是平級的，且這些元素有共同的抽象父類UmlElement，便於使用資料結構進行儲存。但在我將Association等封裝為MyAssociation，而同時Arribute並未封裝，這會出現明明是同級元素卻擁有不同父類，十分不便於使用統一的資料結構進行儲存。
在資料結構的使用上，我還有個缺點。比如在MyClass類中，對於儲存MyAssociation、MyOperation等元素的各個ArrayList，不應當是互相獨立的、靠容器名來區分其內容的不同。而是應當建立一個這些MyXXX
HashMap，其key為ElementType，其value為對應MyXXX物件 向上轉型介面的ArrayList。這樣即可通過ElementType直接得到對應的ArrayList。不是向上找程式碼，一行行看存某個型別元素的容器是哪個，再根據容器名訪問，這顯然是個很失敗的設計。
由於頂層MyUmlGeneralInteraction類的構造過程較為複雜，程式碼量很大，最終導致該類超長，理論上應當將構造過程移出去作為一個新類，也算是將構造邏輯和查詢邏輯深度解耦了。
二、總結
- 寫程式碼、容器使用更加熟練了
- 學會寫程式碼前先想怎麼搭架構、會考慮擴充套件性了
- 學會了先把方法宣告寫好，最後再填寫方法內的內容
- 第1、2單元的時候還要強迫自己往層次化設計構思，到第4單元，層次化架構已經是直覺了
- 構思架構的時候學會去查查有沒有現成的設計模式
- 學會了控制執行緒安全的基本方法
- 學會使用一些程式碼分析、建模工具
- 託第一單元的福，正則表示式和遞迴用的是越發熟練了
- 學會看類圖、順序圖、狀態圖了
三、建議
- 建議在每個大專案的合適時機給出一些架構上的提示，並在專案開始就指出一些十分糟糕的架構，而不是到最後專案寫完了才跟同學講什麼架構有什麼優點。學生中的大佬畢竟是少數，許多學生會因為完全不懂而寫出屎一樣的架構（關於架構的提示太少了），結果就是按照這屎一樣的架構撐過了三次作業，完全沒有鍛鍊效果，到最後優秀的架構也沒實現，只是聽老師講了一下。
- 務必優化一下UML單元的指導書，明確語義，建議參考評論區同學們問的問題來完善指導書。因為指導書的描述不清而導致猜謎語一樣的寫程式碼，實在太痛苦，且是在浪費時間。