一、UML解析器設計

?先看下題目：第四單元實現(xiàn)一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖，順序圖，狀態(tài)圖分析器 MyUmlInteraction，實際上我們要建立一個有向圖模型，UML中的對象（元素）可能與同級元素連接，也可與低級元素相連形成層次關系

?輸入：上述三UML圖的邊集（非實體元素）與點集，上下層級元素通過_parent隱式鄰接。值得注意的是，不同于前兩個單元，我們終于回歸了離線算法OFFLINE，I/O通過一行END_OF_MODEL分隔，處理難度減小了

?輸出：針對給出的_name索引到相應的UML元素查詢相關對應圖中信息，復雜的problem是hw15中對循環(huán)繼承的判斷，其他的都能不使用高級算法解決掉

?下圖是我對本單元作業(yè)設計的類圖，因為三次作業(yè)都是這個架構，下文只按解析器構造流程順序分析。btw感謝肖同學的排雷帖，可見我對UML的理解不夠深入，UMLAttribute可以出現(xiàn)在順序圖中，不應該簡單歸入類圖元素的子類，不過我這樣還是能活過本單元的

信息轉換——適配器模式

?我構建了抽象類MyEle，以及三個子抽象類對應三種UML圖中的元素，因為接口給出的結點（對應實體的元素）沒有鄰接結點的信息，我有必要自定義類來保存這些信息。能將這種“一些"現(xiàn)存的對象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對象不能滿足的”問題解決的是適配器模式

public class MyAdapt {
    //適配器用于轉換的類
    public static MyEle as(UmlElement e) {
        switch (e.getElementType()) {
            case UML_CLASS: {
                return new MyClass((UmlClass) e);
            }
            case UML_ASSOCIATION: {
                return new MyAssc((UmlAssociation) e);
            }...
//
public abstract class MyEle {
    //My*類對UmlElement對象有一個依賴，MyEle實現(xiàn)基本信息接口，其他由子類分別考量
    private UmlElement ele;
    public MyEle(UmlElement e) {
        this.ele = e;
    }...

?在UmlInteraction構造函數(shù)中，我首先將傳入的UmlElement通過MyAdapt“轉換”成My*對象，后者可以從前者中只存儲我們關心的信息，一些可以忽略的元素UmlEvent / UmlEndPoint等直接在這里過濾掉

建圖

?有了這些準備工作開始建圖，以類圖為例（另兩類圖如法炮制），通過.mdj解析，邊集通過_parent / _reference / UML元素表示，提取后完成建圖。我對作業(yè)中涉及的所有的UmlElement，包括邊集UMLAssociation / UMLGeneralization等都適配自己的類，當然這可有可無，我這樣做是為了遍歷一遍MyEle對象就完成建圖，看起來清晰一點。類圖中的頂級元素是類與接口，都管理著方法與屬性，StarUML中可以對二者進行很多相同操作，有必要為二者創(chuàng)建父類ClassLike（類實體）來復用代碼

?根據(jù)輸入模式，我們在解析器中需要管理按_name索引的Class / StateMachine / Interaction等集合，并且索引查詢中要進行有效與重復檢查。我為了復用代碼采用了泛型容器，分別用Hashmap / Hashset實現(xiàn)有效_name查找表與重復_name池

public class MySet<T> {
    private HashMap<String, T> na2ele = new HashMap<>();
    private HashSet<String> dupName = new HashSet<>();
    public void add(T t) {
        if (t instanceof MyEle) 
            if (na2ele.containsKey(t.getName())) dupName.add(t.getName());
            else na2ele.put(t.getName(), t);
    }
    public boolean contains(String s) { return na2ele.containsKey(s); }
    public boolean isDup(String s) { return dupName.contains(s); }
    ...

?根據(jù)輸入，查詢請求關心ClassLike自身的層次或直接關聯(lián)關系或ClassLike間接繼承/實現(xiàn)的關系，后者如“類的頂級父類 / 實現(xiàn)的全部接口”需要ClassLike繼承鏈上的信息。沒有循環(huán)繼承時繼承鏈為樹形結構，由此，我在MyClassLike定義addFather / getFather / update繼承相關抽象方法。update將extends或implements的ClassLike進行update后再合并信息，置為更新過的狀態(tài)，是遞歸式搜索

?輸出方面，通過與同學交流可以記憶化搜索（查詢時更新），但是這是個OFFLINE問題，同時考慮到題目的數(shù)據(jù)規(guī)模1e2.6，小，在完成建圖之后直接對所有類update，全部元素更新后再進行查詢也沒問題，這樣不用每個查詢方法都先update一下了

PreCheck

?hw15要求進行有效性檢查，上文中查詢前update顯然要放到R002 / R003之間，有效性以_id / _name重復，_visibility等檢查為主，很簡單；R002檢測循環(huán)繼承，輸出繼承環(huán)路上所有元素，當然不用求出環(huán)路，只要求出所有環(huán)路上的元素。MyEle處在繼承環(huán)路上 iff 其處于某階數(shù)大于1的強連通分量上或本身存在自環(huán)或一次以自身為源點的搜索經過本身1次以上，故可使用Tarjan或BFS來檢查

二、OOP心路歷程

?談到架構設計及OO方法理解的演進，我認為自己本學期確實有長進，起碼前兩個Unit次次重構，但后兩個Unit都是先好好分析設計結構再寫的，而且都不很復雜，所以都沒有重構

?Unit1為層次化設計，hw1 / hw2是純純的面向過程，hw3中利用工廠模式根據(jù)實際中的實體為表達式中的對象建立了具有繼承層次關系的類，通過將求導以及化簡操作作為抽象方法，使得因子，表達式啥的都能按照自己的求導法則各自計算導數(shù)、化簡，輸出通過覆寫toString()，這是我首次在作業(yè)中體會到面向對象中多態(tài)的優(yōu)勢。

?Unit2為多線程設計，代碼結構很簡單，采用簡單的生產-消費者模式都行，主要還是通過Java庫及保留字實現(xiàn)Java線程的同步與互斥，這塊一直理不太清又很難調試，所以又重構了好多次，可以說我也是初次接觸在線算法問題，電梯調度的優(yōu)劣是跟數(shù)據(jù)相關的，其實有點玄學，在這里我初步了解了Java的異常機制，這是保證魯棒性的方法之一，Java中還有封裝好的ReentrantLock可重入鎖等鎖，我也做了了解

?Unit3為規(guī)格設計，需要根據(jù)JML封裝官方包中的接口，首先得說JML表意很準確，不用像指導書般反復研究，這個Unit大家實現(xiàn)的接口功能都是一樣，但方法與效果不盡相同，面向對象中就是通過這樣的封裝實現(xiàn)代碼的模塊化，調用者很難為封裝好的方法優(yōu)化，作為實現(xiàn)者有義務實現(xiàn)高效的封裝。面向過程和面向對象肯定不是對立的，我們實現(xiàn)的代碼對外是屏蔽掉的，所以在作業(yè)中我在底層函數(shù)用了很多面向過程風格的代碼

?Unit4為模型化設計，我們接觸的UML脫離了Java，描述的是對象、屬性、狀態(tài)等，更加接近面向對象的本質，作業(yè)方面空間很大，由于hw13就理好了層次，后續(xù)輕松拓展，還第一次使用了泛型容器，節(jié)約了很多代碼量，充分封裝各個層次的操作以模塊化

三、測試理解與實踐

?當然我印象最深刻的是多線程程序測試，程序運行結果與環(huán)境相關，在測試出現(xiàn)問題后很難通過程序本身找到病因，我使用JProfiler + println()才能逐步確定程序卡在了哪里

?測試分兩方面，一是驗證程序的基本功能，二是對極限數(shù)據(jù)或異常輸入測試，前者通過隨機生成樣例數(shù)據(jù)或JUnit單元測試法或對拍實現(xiàn)，后者如電梯換乘調度測試，特殊表達式求導，給定數(shù)據(jù)規(guī)模下復雜度最高的數(shù)據(jù)。我認為注重后者或許對我們更有價值，反正我的Bug都出在極限情況...還有一種測試就是對優(yōu)化過的代碼進行測試，一定得用修改前版本對拍一下，屬實對這一點有ptsd了

?JUnit對我而言很好用，@Before / @Test / @After完整構建了數(shù)據(jù)生成、斷言測試、錯誤分析的測試流程，還在同一項目下就能用，舒服啊

四、收獲總結

?首先我在本學期通過Java認識到面向對象的印象深刻的特征：封裝與多態(tài)

?封裝定義為隱藏對象的屬性和實現(xiàn)細節(jié)，僅對外公開接口，我最開始對每個屬性幾乎都寫了get / set，但這樣屬性的隱藏原則就沒意義了，我理解的封裝是沒有需求就不開放屬性的查詢或方法的調用，所以屬于對象“份內事”的方法也盡量用private修飾。封裝的優(yōu)勢顯然，首先封裝隱藏了屬性，保證了程序的數(shù)據(jù)安全，封裝方法，可以使程序設計更加模塊化，比如Unit4中可將三種圖的查詢分派給三種管理類，這樣也能降低類的平均復雜度，還有一點是封裝的代碼拓展性強，需要改變程序功能時，調用者往往不用改寫，只需對封裝的對象中的數(shù)據(jù)結構與方法進行修改，這也是課程迭代開發(fā)模式下的要求。當然，既然有這個信息隱藏原則，調用者就很難根據(jù)實際問題對封裝對象作出調整，導致封裝對象已經很難有優(yōu)化的空間，所以使用封裝時，調用者得對對象有一個大體的了解，比如在Unit3中我因為對Hashmap的底層實現(xiàn)不了解，初始容量過大引發(fā)了隱患；實現(xiàn)者則需合理利用時空資源保證程序的整體良性

?多態(tài)，我理解的是同一類型對象引用在運行時可以使用不同的方法以實現(xiàn)“多種形態(tài)”，一種形式是子類Override方法后使用父類類型引用，還可以是由不同類實現(xiàn)的接口。通過多態(tài)在Unit1實現(xiàn)表達式中不同因子的求導，在Unit4中可以讓數(shù)據(jù)結構不同的Class / Interface（單/多繼承）共享一份Tarjan代碼，多態(tài)巧妙在我們無需去if-else所引用的對象實際是什么類型，調用的方法采用對應繼承鏈上最近的版本，所以多態(tài)中想要擴展新子類很簡單，只需要符合引用者的行為邏輯，引用新子類的對象則無需修改代碼

?當然一些別的特征也很酷，我們可以通過繼承復用父類的代碼，也可以通過泛型類來復用代碼，并且實現(xiàn)類似多態(tài)的效果，不過泛型類在構造傳入類型時，其所管理的類型就確定了，所以我覺得泛型倒有一點c/c++中#define的意思

?不難看出，上面這些特征，無論是類也好，接口也好，其共性是對對象行為范式的一種抽象，OO語言不同于PO語言的一點就是它給了一套這種抽象的機制，所以面向對象編程更貼近實際，我們代碼的結構往往對應實際中的邏輯關系，可能這也是Java的優(yōu)勢，雖然不精煉，但很直觀易懂

?在理論網課 / 實驗課中，我也學到了OO設計模式與原則，OO的可維護性強，很適合于迭代開發(fā)與復雜系統(tǒng)的整體設計，學習OO編程思想，更深入地理解Python / C++等的OO機制了

五、我的改進意見

• 看到這么多同學吐槽實驗課我就放心了，我認為實驗課有必要給同學們一定的反饋，具體的形式可以是編程性實驗之后可以在平臺上像作業(yè)一樣了解測試情況并且進行Bug修復

• 感覺后兩Unit對可維護性要求降低了，Unit1中嵌套的出現(xiàn)打破了原本簡單的表達式到因子的層次關系，Unit2中多部電梯的出現(xiàn)改變了控制類的數(shù)據(jù)結構，也改變了線程同步的條件，而Unit3 / 4在迭代開發(fā)中基本是跟隨指導書在上一次作業(yè)中多寫些方法增加功能就okay了，反正就是對原先的作業(yè)架構的沖擊力不夠大，應該提高難度，btw程序高效性也很重要，希望后兩個Unit能開啟性能分

• Unit3可以放到前面，體現(xiàn)出類規(guī)格，層次間的規(guī)格

• 互測本意應該是驅動大家學習其他同學代碼中的設計策略吧，建議發(fā)動Hack的時候得提交自己發(fā)現(xiàn)的Bug的位置，防止互測變成純黑箱互測

六、網課學習體會

?條件艱苦的線上網課，頗懷念線下的課堂氛圍和peer pressure呢

?感謝仍離同學們最近的老師與助教們~