20155312 2016-2017-2 《Java程序設計》第十週學習總結

時間 2019-11-12

原文原文鏈接

20155312 2016-2017-2 《Java程序設計》第十週學習總結

## 課堂內容總結html

數組
- 遍歷數組：
  - for(...,arr)
  - for(i=0;i<arr.length;i++)
  - for(i=arr.lengthl;i>0;i++) arr[i-1]
- 遞歸java
  
  學習內容總結
網絡
- 局域網：LAN
- 廣域網：WAN
協議
- 應用層協議
  - 超文本傳輸協議：HTTP
    - 是一種請求響應協議
    - 默認80號端口上的TCP
    - HTTP請求包括三個部分：
      git
      - 第一部分具體以下：
        算法
        
        其中請求方法有如下七種：
      - URL：互聯網資源的惟一地址->java.net.URL類
        
        URL構造方法：
        vim
        
        URL實例調用openStream()打開一個URL流==URLConnection的getInputStream()
        
        構造一個URLConnection實例：openConnection()
    - HTTP請求包括三個部分
      數組
  - FIP
  - telnet
- 傳輸層協議
  - TCP
  - UDP
- 網絡層
  - "街道地址"：IP（端口是網絡系統中地址的最小單位）
    ## 學習過程當中的問題
問題一：HTTP請求的7種方法GET，POST，HEAD，OPTIONS，PUT，DELETE，TRACE之間有什麼不一樣？其具體含義是什麼？
解決：通過查閱資料，發現一共有八中請求方法，除了上述7種，還有CONNECTION。他們的差異以下：

GET方法：它本質就是發送一個請求來取得服務器上的某一資源。
1. 資源經過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。
2. GET請求中，永遠不會包含呈現數據。
3. eg:GET /C/9/5/1_kfanning.jpg HTTP/1.1
POST方法:向URL指定的資源提交數據或附加新的數據。
1. 通常來講，提交表單數據都用POST方法。
2. GET 與 POST的區別以下：
3. （GET 與 POST的區別）
PUT方法：向服務器提交數據。

PUT方法請求服務器去把請求裏的實體存儲在請求URI（Request-URI）標識下。若是請求URI（Request-URI）指定的的資源已經在源服務器上存在，那麼此請求裏的實體應該被看成是源服務器關於此URI所指定資源實體的最新修改版本。若是請求RI（Request-URI）指定的資源不存在，而且此URI被用戶代理定義爲一個新資源，那麼源服務器就應該根據請求裏的實體建立一個此URI所標識下的資源。緩存

若是一個新的資源被建立了，源服務器必須能向用戶代理（useragent）發送201（已建立）響應。若是已存在的資源被改變了，那麼源服務器應該發送200（Ok）或者204（無內容）響應。若是資源不能根據請求URI建立或者改變，一個合適的錯誤響應應該給出以反應問題的性質。服務器

實體的接收者不能忽略任何它不理解和不能實現的Content-* （如：Content-Range）頭域，而且必須返回501（沒有被實現）響應。若是請求穿過一個緩存（cache），而且此請求URI（Request-URI）指示了一個或多個當前緩存的實體，那麼這些實體應該被看做是舊的。PUT方法的響應是不可緩存的。網絡

HEAD方法：只請求頁面的首部。
DELETE方法：刪除服務器上的某資源。
OPTIONS方法:用於獲取當前URL所支持的方法。
1. 若是請求成功，會有一個Allow的頭包含相似「GET,POST」這樣的信息。
TRACE方法:被用於激發一個遠程的，應用層的請求消息迴路。
CONNECT方法:把請求鏈接轉換到透明的TCP/IP通道。

問題二：網關和代理的區別是什麼？
解決：網關能夠進行協議轉換，而代理不能，只是起代理的做用，好比緩存服務器其實就是一個代理。
問題三：PUT和POST的區別是什麼？
解決：查詢資料，總結以下：

PUT指定了資源在服務器上的位置，而POST沒有。
POST方法和PUT方法請求最根本的區別是請求URI（Request-URI）的含義不一樣。
1. POST請求裏的URI 指示一個能處理請求實體的資源。此資源多是一個數據接收過程，一個網關，或者一個單獨接收註釋的實體。
2. PUT方法請求裏的URI標識請求裏封裝的實體一一用戶代理知道URI意指什麼，而且服務器不能把此請求應用於其它資源（resource）。PUT方法請求裏的實體頭域應該被用於資源的建立或修改。學習
  
  代碼調試中的問題

問題一： URLConnectionDemo1.java中的下面這兩行代碼時什麼意思？

Map<String, List<String>> headers = urlConnection.getHeaderFields();
Set<Map.Entry<String, List<String>>> entrySet = headers.entrySet();

解決：
- 查詢了Map的API，以下圖所示：K是「此映射所維護的鍵的類型」，上段代碼中鍵類型爲String，V是「映射值的類型」，這裏是一個String類型的鏈表。getHeaderFields用於讀取此URL引用的資源。
- Set是一個不包含重複元素的 collection。其成員類型爲Map.Entry<String, List<String>>Map.Entry其中是映射項（鍵-值對）。截圖以下：
- 查詢entrySet方法：它返回此映射中包含的映射關係的 Set 視圖。
  
  代碼託管

上週考試錯題總結

目前暫不知道試題的具體答案。

結對及互評

這周我對搭檔的幫助是和她一塊兒分析電子版教材中網絡方面的代碼，解決咱們不明白的模塊並督促雙方學習。

評分標準

正確使用Markdown語法（加1分）：
- 不使用Markdown不加分
- 有語法錯誤的不加分（連接打不開，表格不對，列表不正確...）
- 排版混亂的不加分
模板中的要素齊全（加1分）
- 缺乏「教材學習中的問題和解決過程」的不加分
- 缺乏「代碼調試中的問題和解決過程」的不加分
- 代碼託管不能打開的不加分
- 缺乏「結對及互評」的不能打開的不加分
- 缺乏「上週考試錯題總結」的不能加分
- 缺乏「進度條」的不能加分
- 缺乏「參考資料」的不能加分
教材學習中的問題和解決過程, 一個問題加1分
代碼調試中的問題和解決過程, 一個問題加1分
本週有效代碼超過300分行的（加2分）
- 一週提交次數少於20次的不加分
其餘加分：
- 週五前發博客的加1分
- 感想，體會不假大空的加1分
- 排版精美的加一分
- 進度條中記錄學習時間與改進狀況的加1分
- 有動手寫新代碼的加1分
- 課後選擇題有驗證的加1分
- 代碼Commit Message規範的加1分
- 錯題學習深刻的加1分
- 點評認真，能指出博客和代碼中的問題的加1分
- 結對學習狀況真實可信的加1分
扣分：
- 有抄襲的扣至0分
- 代碼做弊的扣至0分
- 遲交做業的扣至0分

點評模板：

博客中值得學習的或問題：
- xxx
- xxx
- ...
代碼中值得學習的或問題：
- xxx
- xxx
- ...
基於評分標準，我給本博客打分：XX分。得分狀況以下：xxx
參考示例

點評過的同窗博客和代碼
本週結對學習狀況
- 20155333
- 結對照片
- 結對學習內容
  - 15章
上週博客互評狀況
- 20155206
- 20155317
- 20155232
- 20155205
- 20155207

學習進度條

	代碼行數（新增/累積）	博客量（新增/累積）	學習時間（新增/累積）	重要成長
目標	5000行	30篇	400小時
第一週	4/0	1/3	28/80	下載了JDK和GIT
第二週	61/4	1/4	20/108	在unbuntu中熟練編寫程序，熟練進行文件、目錄等操做
第三週	684/65	1/5	27/108	初步配置vim方便使用，會本身解決一些代碼問題
第四周	1238/749	1/6	23/135	大部分本身補全的代碼片斷不會出現問題，漸漸具有脫離書本編代碼的能力
第五週	627/1987	1/7	20/158	可以幫助其餘同窗發現代碼出錯的緣由
第六週	414/2614	1/8	24/178	可以整理出教材中各類類、接口、方法之間的相互關係，理清知識脈絡
第七週	564/3028	2/9	17/202	借室友的書進行學習，因此學習時更加註重理解和記憶
第八週	280/3592	1/11	20/219	借室友的書進行學習，因此學習時更加註重理解和記憶
第九周	300/3872	2/12	20/239	借室友的書進行學習，因此學習時更加註重理解和記憶
第十週	899/4172	1/14	18/259	對Java在網絡上的應用有了更多瞭解