1. 第四單元：StarUml檔案決議
本單元采用了圖模型決議UML，
UML檔案可以抽象為圖、子圖、邊的邏輯結構，
在實作中，圖的節點包括類、介面、屬性，子圖包括狀態圖、順序圖等，
采用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第二、三次遍歷設定屬性、連邊，實作圖物件的初始化，這里借鑒了一些python程式設計的思路，通過迭代器、選擇器快速完成資料處理，實作起來代碼撰寫效率比較高，
類、介面節點繼承自可繼承節點抽象類，實作了對繼承的判斷，
總流程為：
umlInteraction互動 - parser建圖 - graph節點存盤資訊 & 定義查詢方法 - umlInteraction互動
2. 架構設計總結
第三次第四次架構較為簡單，這里主要借助JML規則、UML圖的知識，對前兩次作業的架構進行回顧，
2.1 物件概念的提取
面向物件的第一步就應當是提取出物件概念，并找出繼承、關聯關系，進行封裝，
在運算式求導作業中，物件概念的提取的原則是規則，對于初等函式，需要實作的求導規則為：
-
線性法則
-
乘除法則（萊布尼茨公式）
-
鏈式法則
-
特殊函式求導（冪函式、三角函式、對數函式、指數函式、....）
通過這些法則理論上生成任何初等函式的導數，即在初等函式范圍內，求導規則具有完備性，
基于這種思想，結合運算式樹模型完成了物件概念的提取，每一個運算式樹上的節點作為一個Item物件存在，同時代表一個基礎的求導規則體，
對于化簡，實作的部分規則為：
- 節點自我化簡
- 節點之間加減乘化簡
- 三角函式+加減乘化簡
考慮到化簡規則和求導規則的對應關系不清晰，因此單獨建立了化簡介面，在運算式樹上通過遞回訪問介面方法實作化簡，這種架構的不足之處在于，每一個化簡規則被分散在了多種運算式樹節點上，不利于維護，而運算式樹節點的分類是根據求導規則進行的，
一種改進方法是對節點物件添加運算規則，化簡法則通過對運算規則的操作間接完成化簡，
另外節點之間化簡搜索空間非常大，可能還需要一些隨機化方法完成化簡，還應添加一些隨機化的化簡規則，
對于第二單元作業，電梯調度的物件概念提取的原則為狀態，借助UML圖的知識我們可以看到，并發程式可以由時序圖描述，而時序圖中每一個物件可以被視為一個狀態機，狀態機之間通過訊息的傳遞完成并發任務，
因此，應當抽取了需要維護狀態的概念作為物件，同時每個物件的狀態數目不宜過多，且內部聯系緊密，外部聯系疏松，這里抽取的三個狀態為策略快取、調度板、電梯狀態，
同時，MainClass中的讀取執行緒、Executor執行緒作為訊息的發出者，負責保持物件間的協作運行，
graph LR MainClass--Requests-->Schedule MainClass--Create-->Elevators Schedule--Check-->Elevators Executor--Operate-->Elevators Executor--Notify-->Schedule Schedule--Update-->Executor Schedule--Adapt-->Method第三次作業直接實作了提供的介面，社交網路使用的是圖論模型，這里使用了點、點集合作為物件，
第四次作業UML檔案決議，同樣采用的是圖模型，而這里使用的是查詢的內容的邏輯結構為物件，包括類、介面、屬性、狀態圖、順序圖等，
2.2 物件創建模式
第一單元運算式求導課程中，第一次討論了物件創建模式的問題，
這一單元主要的程式設計為:
運算式讀取 --> 運算式元素物件 --> 呼叫元素求導方法 --> 呼叫元素輸出方法
不過在一開始運算式讀取模塊中，使用了狀態機模型，但實作的較為復雜，難以維護，在第二次、第三次作業中，參考了工廠設計模式，一個重要的改進就是強化了狀態機模型和運算式元素物件之間的耦合關系，對于每一類運算式元素，采取獨立的決議器，各個決議器分層決議，每一個決議器類似于一個工廠，
這種方式的優勢在于，較好地將需求中的歸納定義和運算式元素物件的結構映射在了設計架構中，一個還應當改進的方面是回圈依賴問題，可以通過抽象出統一的決議器介面，再對決議器物件進行組裝來解決，類似于抽象工廠模式，
在第二單元作業中，采用了這種在再組裝的策略，分別為執行器模塊、調度器模塊、策略模塊、電梯模塊，各個模塊在MainClass完成對接，模塊之間的實作細節對其他模塊不可見，這樣就避免了模塊組裝時產生的回圈依賴問題，可以理解為所有模塊都依賴于規則集合，而組裝的程序又依賴于全部規則集合、模塊實作集合，
抽象工廠模式/再組裝的優勢在于，采用了“模塊化”的生產理念，各個部門在同一的規則下行事，部門與規則之間的聯系強于部門之間的聯系，避免出現部門之間的回圈依賴，或者說互相扯皮、推卸責任、“拋皮球”情況的發生，
先進的社會是法治的，
而在第四次作業中，采用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第二、三次遍歷設定屬性、連邊，實作圖物件的初始化，這里借鑒了一些python程式設計的思路，通過迭代器、選擇器快速完成資料處理，實作起來代碼撰寫效率比較高，
其實無論哪種物件構建模式，都應遵循貼近實際、簡潔易維護的原則，貼近物件資料結構，問題的邏輯結構，不要刻意迎合某個設計模式，不管黑貓白貓，能捉老鼠的就是好貓，
3. 對面向物件方法的理解
面向物件的方法是對事物刻畫的一種方式，
從宏觀層面上來看，世界的構造具有同構性，例如，地球繞太陽運動，而月球又繞地球運動，從科學的角度來看，這背后具有相似的物理原理和數學規則，可以通過數學方法進行抽象，
面向物件將這種規則化轉化到了程式中，自然而然地誕生了抽象、分層、復用的特性，
科學的一個重要方法是“奧卡姆剃刀原理”，即“如無必要,勿增物體”，面向物件作為規則的描述體，也具有 “封裝，繼承，多型”的類似特點，“封裝”對外部訪問的限制，“繼承”即對重復規則的限制，“多型”即對介面資訊量的限制，同名介面可以處理更多資訊，
面向物件也是工程學的協作方法，從工程化的角度而言，標準化是必不可少的部分，標準化意味著對產品、模塊的行為有確切的約束，我們只需要知道標準就可以進行協作，而無需知道對方的生產程序，
因此一個高效的程式應滿足模塊化、高耦合、低內聚的特點，
一個成功的面向物件的系統應是完備、簡潔、高效的，
4. 課程識訓
- 思考、實踐、總結了面向物件程式設計的方法論
- 學習了并發程式的設計方法
- 學習了JML語言和UML建模方法
- 實踐了Python、Junit測驗方法
- 簡單實踐了一些優化方法
5. 課程建議
- 希望可以改進教學的順序，JML、UML兩個單元可以先講，因為這兩個單元偏向理論，而另外兩個單元偏向應用，且更為綜合，
- 希望JML、UML單元可以布置一些開放性的作業，
- 希望以后在線課程老師可以出鏡，并且將視頻按知識點分塊，一些MOOC是這樣的，感覺效果會明顯更好些，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1010.html
標籤：面向對象
上一篇：6.1邏輯運算子
下一篇：談談我對C# 多型的理解