BUAAOO第四單元總結與學期回顧

第四單元架構設計

第四單元要完成的是對給定UML元素的建模/統計/分析，考慮到UML元素的組織是樹狀的，很容易想到基於樹狀的數據結構完成

因爲UML元素已經由官方接口給出，所以結點類採用wrapper的形式簡化設計。建圖的過程爲：

1. 根據不一樣元素type選用不一樣的wrapper生成對應結點。其實這裏相似一個工廠（可是使用工廠的動機不夠強烈，所以未採納
2. 將生成的結點放入對應的結點池中
3. 考慮到UML圖已經固定，沒有可預見的動態變動圖結構的需求，採用強制離線的方式建圖：在全部結點生成完畢後，按拓撲序將結點依次從結點池中取出，完成其向父結點的掛載（mount）過程。4. 爲了方便實現中間結果緩存，在父結點完成掛載後顯示地調用setImmutable將其標註爲不可變對象，容許保存查詢緩存

除此之外，實驗性質地嘗試封裝了一個能夠按type對node進行查詢的QueryableNodeList類，效果沒有達到預期

第二次的三條check所有使用checker類完成，單獨根據類與接口的實現/繼承關係創建一個有向圖並在圖上完成相關檢測

此次的架構有些over designed，第一次做業對第二次做業的需求迭代方向並無把控好，好在並無失控

學期回顧與課程建議

這學期的四次做業下來收穫仍是蠻多的，在幾個不一樣的場景中深入審視、理解了一些經典的oo思想，也在實戰中嘗試實現了一些以前沒有機會使用的design pattern，同時也不乏一些本身的實驗性質的探索與嘗試。總的來講，不管是架構觀點仍是工程能力，在這學期中都獲得了至關程度的鍛鍊。

對oo特別是java風格的oo的理解更深了。在形式上咱們能夠簡單地說，oo是【繼承·多態·封裝】，可是實際上這並不能很好地總結oo到底是什麼：js原型鏈也是一種形式的代碼複用，各類追求優雅的語言的閉包特性也能夠很好地隱藏實現細節，它們又不是咱們所理解的classic oo。smalltalk的oo是純粹的對象與消息機制，c++的oo是對其餘編程風格與特性的補充與完善，swift的oo是面向協議而非面向接口的，而python的oo大有元編程的意味……一千種語言，一千種oo，咱們在訓練中所熟知的java的oo不過是oo的一種理解角度。因此很難一律而論地說什麼纔是絕對的oo。因此在這個層面的理解上，咱們的探索不只沒有結束，纔剛剛開始。

即使如此，不管是廣義的仍是狹義的，這學期在oo這方面的理解與實踐也足夠回顧品味了。從最基本的語法特性，到常見的設計模式，到java併發編程，每次做業都是一次全新的工程體驗。咱們在一次一次的迭代中，在工程這個角度觸摸到了oop的初衷：高度複用、易維護、易擴展、人類友好、清晰的架構……

我認爲oo課目前最大的好處就是，在壓力適度的同時，給咱們提供了一個自由探索與試錯的機會。一樣的一個task，用很直線的方式能夠實現，用高度設計的架構也能夠實現，哪一個實現好，哪一個實現很差，在迭代的時候天然就能感覺到——欠設計會致使常常性的重構，過設計又會在維護時明顯地感到重力——這些都是可貴的經驗積累的過程。編程的哲學是實用主義哲學與經驗主義哲學，所以這些訓練對我而言是頗有用處的。

在這個基礎上，我我的對課程設計有以下幾點建議：

1. 適當調整難度曲線。好比第一單元在要求熟練掌握正則表達式的同時迅速展開針對oo特性的訓練，體驗比較陡峭
2. 適當調整部分測試數據集，好比電梯第二次做業的構造數據比例遠大於隨機數據，這致使對一些算法的性能評估出現較大誤差
3. 但願能適當增長併發編程的比重，由於這一部分我的認爲在生成中相對更重要，而目前的訓練對併發安全性、併發性能的涉及程度較輕

白駒過隙，一個學期轉瞬即逝。願來年此時再回首，且聽風吟且把酒。