20135119_塗文斌 實驗二 Java物件導向程式設計

標籤：

北京電子科技學院（BESTI）

實  驗  報  告

 課程： Java        班級：1351           姓名：塗文斌          學號：20135119

 成績：               指導教師：婁嘉鵬    實驗日期：2015.4.17

實驗密級：         預習程度：             實驗時間：15：30~18:00

儀器組次：         必修/選修：選修       實驗序號：（一）

實驗名稱：java物件導向程式設計

實驗目的：1.初步掌握單元測試和TDD

              2.理解並掌握物件導向三要素：封裝、繼承、多態

              3.初步掌握UML建模

       　　 4.熟悉S.O.L.I.D原則

 　　　　 5.瞭解設計模式

實驗要求：1.沒有Linux基礎的同學建議先學習《Linux基礎入門（新版）》《Vim編輯器》 課程

              2.完成實驗、撰寫實驗報告，實驗報告以部落格方式發表在部落格園，注意實驗報告重點是運行結果，遇到的問題(工具尋找，安裝，使用，程式的編輯，調試，運行                    等)、解決辦法（空洞的方法如“查網路”、“問同學”、“看書”等一律得0分）以及分析（從中可以得到什麼啟示，有什麼收穫，教訓等）。報告可以參考範飛龍老                    師的指導

              3. 嚴禁抄襲，有該行為者實驗成績歸零，並附加其他懲罰措施。

              4. 請大家先在實驗樓中的~/Code目錄中用自己的學號建立一個目錄，代碼和UML圖要放到這個目錄中，中沒有學號的會要求重做，然後跟著下面的步驟練                     習。

實驗步驟：

（一）單元測試

（1）三種代碼

　　　　　　　　以成績為例：我們要在一個MyUtil類中解決一個百分製成績轉成“優、良、中、及格、不及格”五級製成績的功能。

　　　　　　　　· 虛擬碼 

　　　　　　　　　　/*

　　　　　　　　　　百分制轉五分制： 

  　　　　　　　　　  如果成績小於60，轉成“不及格”   

　　　　　　　　　　 如果成績在60與70之間，轉成“及格”  

 　　　　　　　　　　如果成績在70與80之間，轉成“中等”  

 　　　　　　　　　　如果成績在80與90之間，轉成“良好”  

 　　　　　　　　　　如果成績在90與100之間，轉成“優秀” 

 　　　　　　　　　　 其他，轉成“錯誤”

　　　　　　　　　　*/

　　　　　　　　　·產品代碼

　　　　　　　　　

　　　　　　　　或許會擔心存在一些bug，那麼我們還要寫測試代碼。

　　　　　　　　·測試代碼

　　　　　　　　測試代碼需要多組，並將各種情況全部都測試一遍，情況如。

　　　　　　　　

　　　　　　　　測試結果出現test failed 1，說明MyUtil的代碼檢查出了一個bug，現在來修改MyUtil.java的代碼

　　　　　　　　

　　　　　　　　以為這樣就結束了嗎？你錯了，一般代碼在邊界處最容易出錯，我們還沒有測試邊界情況，我們對輸入為“0，60，70，80，90，100”這些邊界情況進行　　　　　　　　測試的代碼如下：

　　　　　　　　

　　　　　　　　可以看出又出現了一個bug，接下來繼續修改MyUtil.java，代碼如下：

　　　　　　　　

　　　　　　　　這下測試結果通過了。

　　　　　　　　我們把MyUtil.java提供給別人使用時，心裡比較有底氣了。那如何保證單元測度是充分的呢？我們的一般要求是測試代碼要比產品代碼多。如何寫測試，　　　　　　　　　《單元測試之道》提出了Right-BICEP的方法，大家可以參考一下。 軟體是由多人合作完成的，不同人員的工作相互有依賴關係。軟體的很多錯誤都來　　　　　　　　　源於程式員對模組功能的誤解、疏忽或不瞭解模組的變化。如何能讓自己負責的模組功能定義盡量明確，模組內部的改變不會影響其他模組，而且模組的質　　　　　　　　量能得到穩定的、量化的保證？單元測試就是一個很有效解決方案。

（2）TDD(Test Driven Devlopment, 測試驅動開發)

簡單的理解就是：先寫測試代碼，在寫產品代碼，這種測試方法叫做“測試驅動開發”（TDD）。

*TDD的一般步驟如下：

• 明確當前要完成的功能，記錄成一個測試清單
• 快速完成編寫針對此功能的測試案例
• 測試代碼編譯不通過（沒產品代碼呢）
• 編寫產品代碼
• 測試通過
• 對代碼進行重構，並保證測試通過（重構下次實驗練習）
• 迴圈完成所有功能的開發

　　Java中有單元測試工具JUnit來輔助進行TDD，我們用TDD的方式把前面百分制轉五分制的例子重寫一次，體會一下有測試載入器支援的開發的好處。

　　步驟如下：

（1）開啟Eclipse,單擊File->New->Java Project建立一個TDDDemo的Java項目，把滑鼠放到項目名TDDDemo上，單擊右鍵，在彈出的菜單中選定New-　　　　　　          >Source Folder建立一個測試目錄test

　　　　

（2）我們把滑鼠放到test目錄上，單擊右鍵，在彈出的菜單中選定New->JUnit Test Case建立一個測試案例類MyUtilTest。

　　

注意：我們增加第一個測試案例testNormal,注意測試案例前一定要有註解@Test,測試案例方法名任意。

（3）先寫出MyUtilTest肯定會出現錯誤，因為都沒有產品代碼，怎麼進行測試，接下來就是寫產品代碼。

 

（4）我們把滑鼠放到MyUtilTest.java上，單擊右鍵，選擇Run as->JUnit Test。

（5）測試結果出現了一個紅條（red bar）,說明測試沒通過，測試結果出現了一個綠條（green bar）,說明測試通過了。

（6）繼續經過修改MyUtil.java的代碼，測試之後得到：

這樣就完成了一個巨大的工程。

不管用不用TDD，寫出高品質的測試案例才是最重要的，如何進行單元測試，大家可參考一下《單元測試之道》這本書。另外，《Agile Java 中文版》展示了如何將Java和TDD進行有效整合，通過TDD驅動項目開發，有興趣的可以參考。

（二）物件導向三要素

（1）抽象："去粗取精、化繁為簡、由表及裡、異中求同"的抽象能力很大程度上決定了程式員的程式設計能力。

　　

（2）封裝、繼承與多態

　　 物件導向(Object-Oriented)的三要素包括：封裝、繼承、多態。

 　　Dog類通過使用類和存取控制（private,public）隱藏了屬性color,開放了介面setColor(),getColor(),bark()和toString。Dog類是一個模組，我們可以通過下面的代碼使用它，測試代碼與運行結果如下 ：

　　

      

(3)我們可以用UML中的類圖來描述類Dog,首先我們在實驗樓的環境中開啟shell，在命令列中輸入umbrello，開啟UML建模軟體umbrello.

UML建模之後的模型如下：

我們可以看到，在UML 裡，一個類的屬效能顯示它的名字，類型，初始化值，屬性也可以顯示private，public，protected。 類的方法能顯示它們的方法名，參數，傳回型別，以及方法的private，public，protected屬性。其中：

• +表示public
• #表示 protected
• -表示 private

我們看到Dog類和Cat類都有Color屬性和相應的setter和getter方法，明顯違反了前面提到的DRY原則，我們可以通過繼承解決這個問題，把Color屬性和相應的setter和getter方法放到父類Animal中，如以下UML較圖所示：

（三）設計模式初步

（1）S.O.L.I.D原則

　　　物件導向三要素是“封裝、繼承、多態”，任何物件導向程式設計語言都會在文法上支援這三要素。如何藉助抽象思維用好三要素特別是多態還是非常困難的，S.O.L.I.D類設計原則。

　　　OCP是OOD中最重要的一個原則，OCP的內容是：

• software entities (class, modules, function, etc.) should open for extension,but closed for modification.
• 軟體實體（類，模組，函數等）應該對擴充開放，對修改封閉。

 　　SRP的內容是：

• There should never be more than one reason for a class to change
• 決不要有一個以上的理由修改一個類

　　LSP的內容是：

• Subtypes must be substitutable for their base types
• Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
• 子類必須可以被其基類所代
• 使用指向基類的指標或引用的函數，必須能夠在不知道具體衍生類別物件類型的情況下使用它
• 　　ISP的內容是：Clients should not be forced to depend upon interfaces that they do not use

　　客戶不應該依賴他們並未使用的介面

 

　　DIP的內容是：

• High level modules should not depend upon low level modules. Both should depend upon abstractions
• Abstractions should not depend upon details. Details should depend upon abstractions
• 高層模組不應該依賴於低層模組。二者都應該依賴於抽象

抽象不應該依賴於細節。細節應該依賴於抽象

（2）模式與設計模式

　　電腦科學中有很多模式:

• GRASP模式
• 分析模式
• 軟體體繫結構模式
• 設計模式：建立型，結構型，行為型
• 管理員模式： The Manager Pool 實現模式
• 介面設計互動模式
• …

這裡面最重要的是設計模式，在物件導向中設計模式的地位可以和面向過程編程中的資料結構的地位相當。

（四）練習：使用TDD的方式設計關實現複數類Complex。

虛擬碼：

1，設計一個複數類，將複數的實部和虛部分別用變數表示。

2，通過實部和虛部分別相加減實現複數的相加減。

3，按照複數的格式將複數列印出來。

測試代碼：

產品代碼：

2.實驗報告中統計自己的PSP(Personal Software Process)時間

步驟	耗時	百分比
需求分析	60min
設計	60min
代碼實現	60min
測試	60min
分析總結	60mim

 

3.單元測試的好處：

（1）能使得編譯代碼更加具有條理性。

（2）單元測試發現的問題很容易找到問題所在。

（3）可以減少不必要的耗時。

五、參考資料

1.《UML精粹》 2.《構建之法 （電子版）》,著者鄒欣Blog 3.《深入淺出設計模式》 4.《解析極限編程》 5.《單元測試之道》

1. 《代碼大全》
2. 《代碼的抽象三原則》
3. JUnit
4. umbrello

六、工具

StarUML

20135119_塗文斌 實驗二 Java物件導向程式設計