OO最後一次做業

時間 2019-12-10

標籤最後一次简体版

原文原文鏈接

終於開始最後一次做業了，是時候爲這學期oo畫一個圓滿的局句號了。編程

回首這學期的OO經歷，一路走來，通過了開始對面向對象的初步接觸，而後就是充滿痛苦回憶的多線程，接下來到了使人焦頭爛額的規格設計，最後是測試和論證，中間還穿插着幾回（用來放鬆的）博客做業。這些做業把我這個學期填充的十分充實。安全

那麼仍是先把此次做業寫完再說。多線程

測試與正確性論證

這一部分接觸了兩種論證手段，就是測試和正確性論證。框架

測試使用了junit4的測試框架，針對每一個方法來進行規格測試。核心在於構造完備的子集，保證能覆蓋到每一條語句以及每一種狀況下，方法都能正確完成。初次接觸junit4，感受仍是挺簡單實用的一種測試方式。工具

優勢：直觀，覆蓋率和測試結果都能直觀顯示出來。學習

缺點：難以覆蓋全部狀況。且對於repOK這些方法沒有辦法測試與覆蓋。測試

正確性論證是基於邏輯來驗證本身的代碼是「正確」的，描述本身代碼全部可能的狀況，進行嚴密的邏輯驗證。spa

優勢：覆蓋性強，邏輯性更爲嚴密線程

缺點：對於稍微長一點的方法就很難驗證其正確性，每每須要長篇大論的論證。一份完整的正確性驗證報告估計沒有一二十頁寫不出來。（還好今年是沒有互測這玩意）debug

效果差別：測試是從測試樣例的覆蓋來測試程序的正確性，而正確性論證則是經過邏輯來嚴格的驗證程序正確。總的來講這兩種測試手段都各有用武之地。

OCL語言

ocl語言（即object constraint language，對象約束語言）從名字就能看出來是一種約束語言。一個約束就是對一個（或部分）面向對象模型或者系統的一個或者一些值的限制。UML類圖中的全部值均可以被約束，而表達這些約束的方法就是 OCL。

OCL的基礎是數學中的集合論和謂詞邏輯，而且它有一個形式化的數學語義，可是它並無使用某種數學符號。由於雖然數學符號可以清晰的、無歧義的表達事物，可是隻有極少的專家能夠看懂。因此數學符號並不適合用於一個普遍應用的標準語言。

用OCL能夠描述四類約束，分別是不變量、前置條件、後置條件和監護條件。

1）不變量是在屬性的生命期內一直保持爲真的規則。

2）前置條件是在一個操做被調用時必須爲真的約束。它是一個斷言，不是可執行語句。

3）後置條件就是在操做完成時必須爲真的約束。它不是可執行語句而是斷言，必須爲真。

4）監護規則是在對象可以從一種狀態轉變爲另外一種狀態前其值必須爲真的約束。

類似點：都有前置條件和後置條件，都是無二義性的精確語言，來對程序進行約束

不一樣點：OCL語言標準更完善，表現力更強；JSF能夠看作一種簡化過的OCL語言。

第14次做業UML圖

類圖

UML順序圖

UML狀態圖

學期總結

寫完這個部分而後提交，這學期的oo旅程就算正式結束了。（應該會是星期一夜寫完，作一次ddl戰士）用博客來回顧一下這學期的面向對象之路，也回顧一下這個學期是否讓我感到充實。

微小的工做：

這學期的OO一共分紅了四個單元，每一個單元三次編程做業（最後一次調整了只有兩次，可喜可賀）加上一個總結性的博客。回過頭來總結一下這四個單元究竟學了什麼：

（1）JAVA編程入門，面向對象編程入門（+互測入門）：

這一部分的三次做業是：多項式相加，傻瓜電梯，ALS電梯。

說是面向對象編程入門，實際上大多數同窗作第一次做業以前連JAVA都沒有寫過，第二次做業開始就要寫有必定規模的面向對象程序了。能夠說是一週的JAVA速成加上一週的面向對象速成加上一週的面向對象進階。

（2）JAVA多線程從入門到入土：

這一部分的三次做業是：三線程ALS電梯，IFTTT實現文件監視器，100輛出租車調度程序。

這一部分難度有了質的飛躍，實現JAVA多線程編程。途中debug，編代碼（主要是電梯）遇到了各類各樣的不明因此的奇奇怪怪的bug，讓咱們認識到多線程的強大以及線程安全的重要性。不過一樣只有一週時間就要咱們寫完一個難度極高的電梯，也能夠說是一週的JAVA多線程速成了。

（3）面向規格的設計（與互測）：

這一部分的三次做業是：在出租車程序中增長道路流量，增長紅綠燈，增長可迭代的出租車。

這一部分仍然是用多線程實現JAVA的多線程，可是側重點變了。由實現程序的正確性（包括線程安全問題）變成了設計層面問題。如何作出優雅的設計，如何編寫出無懈可擊（不被扣分）的JSF。

（4）測試與論證：

這一部分的三次做業是：基於Junit4的測試與覆蓋，正確性論證，UML圖的繪製（博客）

這一部分的學習任務從編寫轉爲了測試與論證，對於規格、設計的要求也上升了。

總的來講這學期的學習內容仍是十分充足龐大的，涵蓋了除了面向對象的幾乎大部份內容。也難怪有前輩指出，北航面向對象的格局，跟其餘學校是徹底不一樣的。整套面向對象課程體系完整看下來像是一整套程序編程的體系，從正確性到安全性，再到優雅設計，最後是測試和論證；而徹底不像僅僅是面向對象的課程，仍是挺有意思的。

程序的進步：

（1）設計：這部分仍是很明顯的。從一開始寫多項式poly都感受有點費勁，徹底不會面向對象，只能按照提供的框架一步步來寫。二三次電梯的設計雖然能看到一丟丟面向對象的影子，可是設計仍是不夠細，仍然有god類和idiot類出現。到後面兩個星期能寫出難度不小的多線程程序，電梯（雖然bug很多)和IFTTT。尤爲是能在一個星期內寫出來這樣的程序，當時確定是不敢想的。而後寫的出租車已經很有面向對象的風範了，對於抽象對象，提取共性寫方法也逐漸熟練了起來。

（2）測試：從一開始只會system.out，到如今知道了junit4這種方便的測試工具。至於測試別人的代碼，仍是佛系一點吧。

（3）代碼質量：跟1同樣也是很明顯的進步。一開始的ALS電梯出現了一個奇長無比的方法（雖然我也懶得改了），如今看來裏面充斥着各類無用的廢話。包括寫第一次做業和第二次做業時候也還有造輪子之嫌。雖然有些人說造輪子並非徹底沒有意義，但我本身看來這些輪子造的是真的沒有意義。明明有更加方便的工具卻仍是寫了一堆冗長無用的廢代碼，確實很不該該。在瞭解了JAVA的方便以後，各類內置的工具確實比本身造的輪子高到不知到哪裏去，可讀性質量都比之前好了很多。如今看來以前的代碼寫的確實是辣雞啊。

另一點進步就是心態，面向對象真的很鍛鍊心態，讓我更加堅強了。

工程化的一點理解：

以前並無寫過工程啊。。。也並不知道什麼是工程化。

不過仍是得完成做業，在我看來工程化應該是不少人一塊兒完成的。因此對於我的來講，代碼必定要保證精簡和可讀，作好封裝、寫好註釋以及規格。

代碼可讀性強是基本的，畢竟在一個龐大的項目中，出現一個可讀性差的代碼顯然不是明智的。而對於一個寫好的代碼，應該讓項目的其餘人更好的理解本身寫的內容，因此規格和註釋也是十分必要的。

同時還要作好代碼的規範性，統一編程的規範才能讓團隊便於理解和維護。

小小的建議：

這裏對課程的各個方面提出小小的建議和意見：

首先是難度方面的

若是不打算下降難度的話不算什麼建設性意見，能夠直接跳過。畢竟個人oo旅程已經快結束了，再難也跟我不要緊了，但願下屆的學生能撐過來吧hhh。

（1）課程內容方面（做業量）：

課程內容仍是十分豐富的，瑕疵是跨度和難度略大。尤爲是做業量十分充足，一星期一個大工程。面向對象的程序都還不怎麼會寫，就已經要求寫很難的多線程程序了。並且一星期速成多線程，仍是那麼難的電梯，哪怕能寫出來質量也不見得必定很高。並且據說下一屆的os難度會加大，不知道雙重課業壓力之下，下一屆的學生能不能承受住了。

就我本身來講，在oo重壓那一段時間基本是爲了oo放棄了os的，多是由於我太菜了，實在是無力應對這樣兩門課程。

（2）做業安排方面：

多線程電梯很顯然是最難的一次做業了，對於設計的難度且不提，對於線程安全的要求顯然是最高的。安排在剛剛接觸多線程的那一星期有一點難了。固然正值清明節假期時間比其餘的一星期是要多一點。

至於IFTTT我以爲是沒什麼必要的一次做業了。此次做業的目標說是「訓練同窗們針對線程安全問題，如何平衡線程訪問控制和共享對象之間的矛盾」。這一次做業主要自學了一段時間的文件系統，難度主要在文件系統和監控的實現上。而我在實際編寫過程當中耗時最多的是實現，甚至並無太多關注線程安全。而在測試時發現哪怕對於同一個文件的操做，只要是SafeFile類文件的也不太會由於共享對象而出現線程安全問題。我認爲這一次做業的難點實際上是理解指導書，自學文件系統和實現文件監控，甚至沒有怎麼涉及到線程安全問題。

而多線程電梯就不同了。請求不斷的輸入，請求隊列不斷地掃描，還要根據電梯的各類狀態來進行判斷和分配。請求隊列的共享十分明顯，並且對於線程安全的要求至關高，若是哪裏同步出了一點問題都會有意想不到的狀況發生。（指導書上竟然對「線程安全」四個字隻字不提）

因此我認爲能夠刪除IFTTT這一次做業，用兩個星期來編寫三線程電梯。事實上我感受IFTTT此次做業意義真的不是很大，若是用兩個星期來編寫電梯，若是真的能實現好這個電梯，對於線程安全的理解確定不會差的。