從這四個單元來看，除了第三單元對於架構的感受不深，兩外三個單元對架構的要求是比較高的。雖然這三個單元內容主題完全不同，但設計架構的目標是一樣的，就是盡可能地把現實中的邏輯細緻地還原表達出來。
所以oo是什麼？j同學在一次研討課上表示oo在他看來就是將資料和方法集中起來封裝，我認為這個表述沒有觸及到oo的本質，雖然看上去每次作業設計的各種類的形式確實是這樣，有成員變數和方法，但這麼做的核心目的是更好地描述現實邏輯。比如說電梯單元中設計電梯類，有一些成員變數比如執行方向、載客量、乘客，這些成員變數都是為了能夠更加精確地描述電梯這個現實中的事物，電梯的一些方法比如開門、關門、上客、下客，這些方法也是為了更加準確地描述現實中電梯的行為，資料加方法，對應著現實事物的屬性和行為。而對於繼承、介面這樣的性質，也是為了更方便更簡潔地描述現實事物，比如第一單元中讓冪函式、三角函式去繼承乙個項item類，從**來看是減少了不必要的重複描述，提高**復用性，而現實中我們也會認為冪函式和三角函式屬於項的一種，這是乙個很自然地認識，是符合常識符合數學邏輯的認識。而在第一單元架構設計中，正如之前所說，好的架構能夠精確地還原現實行為的邏輯本質，第一單元中前兩次採用的描述通項的架構顯然沒有精確地表現出求導這個行為的本質，而第三次作業的表示式樹的設計將表示式和求導的邏輯描述地更加精確，自然成為了一種比較好的架構。綜上所述，我認為oo是描述現實邏輯的一種手段。
這個課程除了完成作業，另外一大任務是對程式進行測試。實踐表明，所有強測互測**的作業都是沒有認真測試的惡果。
第一單元前兩次作業使用python生成隨機測試樣例，構建了乙個簡易的評測機，但這個評測機僅僅做到了隨機，而忽視了特殊資料邊界資料，沒有完全覆蓋所有的情況，導致互測**。之後借鑑了dalao的思想，通過控制生成表示式的長度來生成一些特殊資料，評測機有所提公升，不過對於wrong format依然無能為力，強測還是出錯。第三次作業忙於重構和馮如杯二審，沒有搭建評測機，結果強測**，算是還了之前糟糕的架構設計欠下的債。
第二單元沒有搭建評測機，所幸沒有出問題。這裡提供一位dalao的第二單元評測機構建思路，我從中學到了很多，獲益匪淺。
第三單元沒有搭建評測機，採用的是junit單元測試，主要是對一些容易出問題的方法如最短路、強連通分量等方法進行了測試，保證了功能的正確，強測過關。
第四單元沒有搭建評測機也沒有進行單元測試，強測果然出問題。這個單元搭建評測機有一些困難，主要是資料不太容易生成。最後採用的是在staruml中畫圖然後進行測試這樣的原始方法，也注定了有一些情況考慮不到，強測出問題情理之中。
總的來說測試這塊做的確實不如人意，是需要進行加強的地方。無論是搭建評測機還是自己手動構建邊界資料都還有很多需要提公升的地方，而不能依賴所謂的形式驗證，形式驗證對於比較簡易的架構或許可以，但遇到大工程時就無能為力了。
總的來說效果還是不錯的，作業和實驗沒有因為線上的問題而遇到什麼困難，平時的課程講授也比較生動有趣，而且對於不清楚的地方可以回看，總的來說課程體驗相比線下課沒有差多少。不過因為線上的原因，同學的討論沒有線下那麼方便，交流上確實受到了影響。
oo是一門很有價值的課程，讓我收穫頗豐，培養了我的工程能力的同時也磨練了我的心態。希望未來的oo課能夠越辦越好。
OO第四單元總結
第一次作業我將umlelement進行分類，新建乙個封裝類uml，用介面和類進行例項化 新建乙個operation類例項化operation元素。在myumlinteraction的初始化，先找到所有的類和介面例項化uml。然後找到所有的方法，例項化operation類，並且將類根據parentid...
OO第四單元總結
這個單元寫 的時候在面向過程的方便和物件導向的清晰架構中反覆橫跳，導致最後寫出來的東西亂七八糟。第一次作業 第一次作業只涉及到了uml的類圖。定義了myclass myinte ce myoperation三個類，儲存attribute等資訊。我的想法是將一條條資訊即乙個個umlelement分類存...
OO第四單元總結
使用乙個類idtree來記錄各個元素之間的父子關係，類myumlinteraction用來實現其餘所有功能。三次作業下來需要實現二十多個方法，類myumlinteraction寫了1000行，架構非常混亂，沒有章法。說白了，這次作業和第三單元一樣，還是圖論，出現了種種問題，暴露出了自己資料結構基礎的...