一、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來檢查
二、OOP心路歷程
? 談到架構設計及OO方法理解的演進，我認為自己本學期確實有長進，起碼前兩個Unit次次重構，但后兩個Unit都是先好好分析設計結構再寫的，而且都不很復雜，所以都沒有重構
? Unit1為層次化設計，hw1 / hw2是純純的面向程序，hw3中利用工廠模式根據實際中的物體為運算式中的物件建立了具有繼承層次關系的類，通過將求導以及化簡操作作為抽象方法，使得因子，運算式啥的都能按照自己的求導法則各自計算導數、化簡，輸出通過覆寫toString()，這是我首次在作業中體會到面向物件中多型的優勢，
? Unit2為多執行緒設計，代碼結構很簡單，采用簡單的生產-消費者模式都行，主要還是通過Java庫及保留字實作Java執行緒的同步與互斥，這塊一直理不太清又很難除錯，所以又重構了好多次，可以說我也是初次接觸在線演算法問題，電梯調度的優劣是跟資料相關的，其實有點玄學，在這里我初步了解了Java的例外機制，這是保證魯棒性的方法之一，Java中還有封裝好的ReentrantLock可重入鎖等鎖，我也做了了解
? Unit3為規格設計，需要根據JML封裝官方包中的介面，首先得說JML表意很準確，不用像指導書般反復研究，這個Unit大家實作的介面功能都是一樣，但方法與效果不盡相同，面向物件中就是通過這樣的封裝實作代碼的模塊化，呼叫者很難為封裝好的方法優化，作為實作者有義務實作高效的封裝，面向程序和面向物件肯定不是對立的，我們實作的代碼對外是屏蔽掉的，所以在作業中我在底層函式用了很多面向程序風格的代碼
? Unit4為模型化設計，我們接觸的UML脫離了Java，描述的是物件、屬性、狀態等，更加接近面向物件的本質，作業方面空間很大，由于hw13就理好了層次，后續輕松拓展，還第一次使用了泛型容器，節約了很多代碼量，充分封裝各個層次的操作以模塊化
三、測驗理解與實踐
? 當然我印象最深刻的是多執行緒程式測驗，程式運行結果與環境相關，在測驗出現問題后很難通程序式本身找到病因，我使用JProfiler + println()才能逐步確定程式卡在了哪里
? 測驗分兩方面，一是驗證程式的基本功能，二是對極限資料或例外輸入測驗，前者通過隨機生成樣例資料或JUnit單元測驗法或對拍實作，后者如電梯換乘調度測驗，特殊運算式求導，給定資料規模下復雜度最高的資料，我認為注重后者或許對我們更有價值，反正我的Bug都出在極限情況...還有一種測驗就是對優化過的代碼進行測驗，一定得用修改前版本對拍一下，屬實對這一點有ptsd了
? JUnit對我而言很好用，@Before / @Test / @After完整構建了資料生成、斷言測驗、錯誤分析的測驗流程，還在同一專案下就能用，舒服啊
四、識訓總結
? 首先我在本學期通過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機制了
五、我的改進意見
-
看到這么多同學吐槽實驗課我就放心了，我認為實驗課有必要給同學們一定的反饋，具體的形式可以是編程性實驗之后可以在平臺上像作業一樣了解測驗情況并且進行
Bug修復 -
感覺后兩
Unit對可維護性要求降低了，Unit1中嵌套的出現打破了原本簡單的運算式到因子的層次關系，Unit2中多部電梯的出現改變了控制類的資料結構，也改變了執行緒同步的條件，而Unit3 / 4在迭代開發中基本是跟隨指導書在上一次作業中多寫些方法增加功能就okay了，反正就是對原先的作業架構的沖擊力不夠大，應該提高難度，btw程式高效性也很重要，希望后兩個Unit能開啟性能分 -
Unit3可以放到前面，體現出類規格，層次間的規格 -
互測本意應該是驅動大家學習其他同學代碼中的設計策略吧，建議發動
Hack的時候得提交自己發現的Bug的位置，防止互測變成純黑箱互測
六、網課學習體會
? 條件艱苦的線上網課，頗懷念線下的課堂氛圍和peer pressure呢
? 感謝仍離同學們最近的老師與助教們~
? 馬馬虎虎算是入門了OO，鐵鐵們，共勉
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1008.html
標籤：面向對象
下一篇：6.1邏輯運算子