BUAA_OO_第四單元

1、UML解析器設計

​ 先看下題目：第四單元實現一個基於JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖，順序圖，狀態圖分析器 MyUmlInteraction，實際上咱們要創建一個有向圖模型，UML中的對象（元素）可能與同級元素鏈接，也可與低級元素相連造成層次關係

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

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

​ 下圖是我對本單元做業設計的類圖，由於三次做業都是這個架構，下文只按解析器構造流程順序分析。btw感謝肖同窗的排雷帖，可見我對UML的理解不夠深刻，UMLAttribute能夠出如今順序圖中，不該該簡單納入類圖元素的子類，不過我這樣仍是能活過本單元的

信息轉換——適配器模式

​ 我構建了抽象類MyEle，以及三個子抽象類對應三種UML圖中的元素，由於接口給出的結點（對應實體的元素）沒有鄰接結點的信息，我有必要自定義類來保存這些信息。能將這種「一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能知足的」問題解決的是適配器模式

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實現基本信息接口，其餘由子類分別考量
    private UmlElement ele;
    public MyEle(UmlElement e) {
        this.ele = e;
    }...

​ 在UmlInteraction構造函數中，我首先將傳入的UmlElement經過MyAdapt「轉換」成My*對象，後者能夠從前者中只存儲咱們關心的信息，一些能夠忽略的元素UmlEvent / UmlEndPoint等直接在這裏過濾掉

建圖

​ 有了這些準備工做開始建圖，以類圖爲例（另兩類圖如法炮製），經過.mdj解析，邊集經過_parent / _reference / UML元素表示，提取後完成建圖。我對做業中涉及的全部的UmlElement，包括邊集UMLAssociation / UMLGeneralization等都適配本身的類，固然這無關緊要，我這樣作是爲了遍歷一遍MyEle對象就完成建圖，看起來清晰一點。類圖中的頂級元素是類與接口，都管理着方法與屬性，StarUML中能夠對兩者進行不少相同操做，有必要爲兩者建立父類ClassLike（類實體）來複用代碼

​ 根據輸入模式，咱們在解析器中須要管理按_name索引的Class / StateMachine / Interaction等集合，而且索引查詢中要進行有效與重複檢查。我爲了複用代碼採用了泛型容器，分別用Hashmap / Hashset實現有效_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); }
    ...

​ 根據輸入，查詢請求關心ClassLike自身的層次或直接關聯關係或ClassLike間接繼承/實現的關係，後者如「類的頂級父類 / 實現的所有接口」須要ClassLike繼承鏈上的信息。沒有循環繼承時繼承鏈爲樹形結構，由此，我在MyClassLike定義addFather / getFather / update繼承相關抽象方法。update將extends或implements的ClassLike進行update後再合併信息，置爲更新過的狀態，是遞歸式搜索

​ 輸出方面，經過與同窗交流能夠記憶化搜索（查詢時更新），可是這是個OFFLINE問題，同時考慮到題目的數據規模1e2.6，小，在完成建圖以後直接對全部類update，所有元素更新後再進行查詢也沒問題，這樣不用每一個查詢方法都先update一下了

PreCheck

​ hw15要求進行有效性檢查，上文中查詢前update顯然要放到R002 / R003之間，有效性以_id / _name重複，_visibility等檢查爲主，很簡單；R002檢測循環繼承，輸出繼承環路上全部元素，固然不用求出環路，只要求出全部環路上的元素。MyEle處在繼承環路上 iff 其處於某階數大於1的強連通份量上或自己存在自環或一次以自身爲源點的搜索通過自己1次以上，故可以使用Tarjan或BFS來檢查

2、OOP心路歷程

​ 談到架構設計及OO方法理解的演進，我認爲本身本學期確實有長進，起碼前兩個Unit次次重構，但後兩個Unit都是先好好分析設計結構再寫的，並且都不很複雜，因此都沒有重構

​ Unit1爲層次化設計，hw1 / hw2是純純的面向過程，hw3中利用工廠模式根據實際中的實體爲表達式中的對象創建了具備繼承層次關係的類，經過將求導以及化簡操做做爲抽象方法，使得因子，表達式啥的都能按照本身的求導法則各自計算導數、化簡，輸出經過覆寫toString()，這是我首次在做業中體會到面向對象中多態的優點。

​ Unit2爲多線程設計，代碼結構很簡單，採用簡單的生產-消費者模式都行，主要仍是經過Java庫及保留字實現Java線程的同步與互斥，這塊一直理不太清又很難調試，因此又重構了好屢次，能夠說我也是初次接觸在線算法問題，電梯調度的優劣是跟數據相關的，其實有點玄學，在這裏我初步瞭解了Java的異常機制，這是保證魯棒性的方法之一，Java中還有封裝好的ReentrantLock可重入鎖等鎖，我也作了瞭解

​ Unit3爲規格設計，須要根據JML封裝官方包中的接口，首先得說JML表意很準確，不用像指導書般反覆研究，這個Unit你們實現的接口功能都是同樣，但方法與效果不盡相同，面向對象中就是經過這樣的封裝實現代碼的模塊化，調用者很難爲封裝好的方法優化，做爲實現者有義務實現高效的封裝。面向過程和麪向對象確定不是對立的，咱們實現的代碼對外是屏蔽掉的，因此在做業中我在底層函數用了不少面向過程風格的代碼

​ Unit4爲模型化設計，咱們接觸的UML脫離了Java，描述的是對象、屬性、狀態等，更加接近面向對象的本質，做業方面空間很大，因爲hw13就理好了層次，後續輕鬆拓展，還第一次使用了泛型容器，節約了不少代碼量，充分封裝各個層次的操做以模塊化

3、測試理解與實踐

​ 固然我印象最深入的是多線程程序測試，程序運行結果與環境相關，在測試出現問題後很難經過程序自己找到病因，我使用JProfiler + println()才能逐步肯定程序卡在了哪裏

​ 測試分兩方面，一是驗證程序的基本功能，二是對極限數據或異常輸入測試，前者經過隨機生成樣例數據或JUnit單元測試法或對拍實現，後者如電梯換乘調度測試，特殊表達式求導，給定數據規模下複雜度最高的數據。我認爲注重後者或許對咱們更有價值，反正個人Bug都出在極限狀況...還有一種測試就是對優化過的代碼進行測試，必定得用修改前版本對拍一下，屬實對這一點有ptsd了

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

4、收穫總結

​ 首先我在本學期經過Java認識到面向對象的印象深入的特徵：封裝與多態

​ 封裝定義爲隱藏對象的屬性和實現細節，僅對外公開接口，我最開始對每一個屬性幾乎都寫了get / set，但這樣屬性的隱藏原則就沒意義了，我理解的封裝是沒有需求就不開放屬性的查詢或方法的調用，因此屬於對象「分內事」的方法也儘可能用private修飾。封裝的優點顯然，首先封裝隱藏了屬性，保證了程序的數據安全，封裝方法，可使程序設計更加模塊化，好比Unit4中可將三種圖的查詢分派給三種管理類，這樣也能下降類的平均複雜度，還有一點是封裝的代碼拓展性強，須要改變程序功能時，調用者每每不用改寫，只需對封裝的對象中的數據結構與方法進行修改，這也是課程迭代開發模式下的要求。固然，既然有這個信息隱藏原則，調用者就很難根據實際問題對封裝對象做出調整，致使封裝對象已經很難有優化的空間，因此使用封裝時，調用者得對對象有一個大致的瞭解，好比在Unit3中我由於對Hashmap的底層實現不瞭解，初始容量過大引起了隱患；實現者則需合理利用時空資源保證程序的總體良性

​ 多態，我理解的是同一類型對象引用在運行時可使用不一樣的方法以實現「多種形態」，一種形式是子類Override方法後使用父類類型引用，還能夠是由不一樣類實現的接口。經過多態在Unit1實現表達式中不一樣因子的求導，在Unit4中可讓數據結構不一樣的Class / Interface（單/多繼承）共享一份Tarjan代碼，多態巧妙在咱們無需去if-else所引用的對象實際是什麼類型，調用的方法採用對應繼承鏈上最近的版本，因此多態中想要擴展新子類很簡單，只須要符合引用者的行爲邏輯，引用新子類的對象則無需修改代碼

​ 固然一些別的特徵也很酷，咱們能夠經過繼承複用父類的代碼，也能夠經過泛型類來複用代碼，而且實現相似多態的效果，不過泛型類在構造傳入類型時，其所管理的類型就肯定了，因此我以爲泛型倒有一點c/c++中#define的意思

---

​ 不難看出，上面這些特徵，不管是類也好，接口也好，其共性是對對象行爲範式的一種抽象，OO語言不一樣於PO語言的一點就是它給了一套這種抽象的機制，因此面向對象編程更貼近實際，咱們代碼的結構每每對應實際中的邏輯關係，可能這也是Java的優點，雖然不精煉，但很直觀易懂

​ 在理論網課 / 實驗課中，我也學到了OO設計模式與原則，OO的可維護性強，很適合於迭代開發與複雜系統的總體設計，學習OO編程思想，更深刻地理解Python / C++等的OO機制了

5、個人改進意見

• 看到這麼多同窗吐槽實驗課我就放心了，我認爲實驗課有必要給同窗們必定的反饋，具體的形式能夠是編程性實驗以後能夠在平臺上像做業同樣瞭解測試狀況而且進行Bug修復

• 感受後兩Unit對可維護性要求下降了，Unit1中嵌套的出現打破了本來簡單的表達式到因子的層次關係，Unit2中多部電梯的出現改變了控制類的數據結構，也改變了線程同步的條件，而Unit3 / 4在迭代開發中基本是跟隨指導書在上一次做業中多寫些方法增長功能就okay了，反正就是對原先的做業架構的衝擊力不夠大，應該提升難度，btw程序高效性也很重要，但願後兩個Unit能開啓性能分

• Unit3能夠放到前面，體現出類規格，層次間的規格

• 互測本意應該是驅動你們學習其餘同窗代碼中的設計策略吧，建議發動Hack的時候得提交本身發現的Bug的位置，防止互測變成純黑箱互測

6、網課學習體會

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

​ 感謝仍離同窗們最近的老師與助教們~

​ 馬馬虎虎算是入門了OO，鐵鐵們，共勉