OOP第四章博客

OOP第四章博客做業

（1）本單元做業架構設計

1. 1）針對於第一次做業，我是將所給類進行了本身的封裝，在MyUmlInteraction類裏面進行關係的創建，這裏把所給的UmlClass創建好，同時有id2Umlclass（id到UmlClass）和name2UmlClass（name到UmlClass）；UmlInterface一樣的創建方式；

   2）把和相關UmlCLass類的屬性，操做，操做的參數，和關聯，接口再填入到包裝的UmlClass類中；即將一個類全部的東西都包裝爲一個ClassUml（UmlInterface相似），將全部的「東西裝進去」，而且創建相應的查找方法，爲接口服務；

   3）針對UmlOperation類一樣進行一個包裝，將參數填入其中；

   4）針對UmlAssociation類也創建包裝，將End填入其中；（事實證實這一步對於測試要求無心義！）

   5）在具體的實現過程當中，首先掃描一遍，創建全部的UmlClass的聯繫，保存其餘UmlElement；在第二次循環時，依次創建繼承（UmlGeneralization）、屬性（UmlAttribute）、操做（UmlOperation）、參數（UmlParameter）、關聯端（UmlAssociationEnd）和接口實現（UmlInterfaceRealization）；

   6)將具體的查詢細節放置在對應的類中進行實現，向外部提供接口；
   

2. 1）第二次做業的設計，沿襲第一次設計的風格，進一步抽象；

   2）把MyGeneralUmlInteration類和具體的包裝類的耦合性下降，直接提供一個StarUml類（終極抽象）

   3）在StarUml類中進一步細化查詢，分爲針對Class的StarUmlClass類、針對狀態圖的StarUmlState類和針對時序圖的StarUmlSeqence類；

   4）StarUmlclass類添加了check功能，而且向上一層次提供接口；

   5）StarUmlState實現關於狀態圖的關係創建和查詢功能的實現以及外部函數接口

   6）StarUmlSequence實現了關於時序圖的關係創建和查詢功能實現以及外部函數接口；

   7）最後把頂層的函數依次調用相關函數實現解耦（可是層次化可能有點多，致使同名函數一連串，這也是爲了防止混淆！）

（2）四個單元中的架構設計及OO方法的理解演進

1. 第一個單元：這個單元毫無架構設計性可言，徹底是強轉面向過程，致使代碼架構極其複雜以至我再次回看時一時竟沒法理解（😭）；總體是在不斷地重構中推到->新建->推到->新建->推到？？，最後選擇湊合！因而，層次化不清晰，代碼大量冗餘，耦合性極高！
2. 第二個單元是多線程，此時對於架構終於明白了一點，可是呢，對於多線程又不懂了，因此仍是通過了一次重構，第一次簡單的電梯，徹底按照簡單着來，選擇熟悉；第二次選擇了分離結構，控制器（dispacher）提取電梯請求（input）再發送給電梯（elevator），總體上按照三個線程類來進行；包括第三次做業也是基於此來設計，同時引入了選擇客戶分配；
3. 第三個單元是JML；這個單元的設計，其實如今來看會發現有些東西！好比，如今來看這個JML的第一次做業，簡單的作完後是第二次好像重來？？畢竟是有時間限制，其實這一單元因爲時間的限制會致使在架構設計上須要進行深思熟慮，否則不只堆在一塊兒不利於bug查找，也會致使低效率！我在這裏的翻車點是第三次做業沿襲第二次設計，致使層次化過於混亂，因而引入了一個多餘的層次，致使函數的調用老是會多一次白費力氣，可是這個函數倒是一個被常用的函數，因而時間翻倍，直接GG！總體來看，這一單元的架構設計並很差，耦合性較高，不知道該如何解耦，也沒有很好的設計，有些粗糙！
4. 第四單元以前敘述過不詳細介紹！

四個單元對於OO方法的理解呢，最初是徹底不理解的，如今呢，感受初窺門徑？感受面向對象就是一種抽象層次，設計邏輯關係的思想，而面向過程就是，別問，問就是下一步幹啥！面向對象就是誰來幹啥；

通過四個單元，感受第一個單元是入門，第二個單元是理解， 第三個單元是應用，第四個單元是綜合起來的感受！由於這個時候寫做業感受已經有一些順滑，一些明悟了！（真是不容易呢）

（3）測試理解和實踐的演進

在第一單元和第二單元的測試中，可能主要偏向於使用數據來儘量遍歷的方法來實現程序的正確性，而後對於邏輯性的檢查不是不少；更沒有使用過單元測試這種方式；

在第三單元和第四單元中因爲做業的類型和前兩個單元的不一樣，這時我發現，這種單個測試方法的做業，單元測試，或者說對於每一個方法進行邏輯性檢查是一種最有效且bug最不容易發生的方法！並且，對於debug也是相對簡單，由於錯誤容易抓獲，這時數據的效果反而不是那麼有效；固然，邏輯性的檢測，也須要頭腦清晰，建議在完成後和小夥伴進行思惟碰撞，提早互測（真實致命）！

綜合四個單元，對於不一樣的做業，不一樣的測試方法的效果確實是大不同，不能一味依據數據生成器，必須針對做業來進行選擇!

（4）課程收穫

首先，做爲一個成功度過OO的北航學子，收穫是終於放假啦頗多的！em，沒錯，頗多的！

這算是第一次接觸面向對象，遙想第一次寫做業差點當場暴斃，滿腦子想的爲何會有這種設計方法？有什麼優點呢？

如今看來，面向對象好啊（真香）；爲何呢？以往的面向過程，注重的是過程設計，在寫做業時，會無腦一路往下走，可是感受很凌亂，對於debug時極爲的不利（相對於面向對象來講，固然，設計很差，debug其實沒差異，囧）；可是面向對象的設計思想——也是老師一直提到的，也是我一直嘗試學習領悟的，如何把一個問題，抽象爲幾個對象和對象之間的邏輯，經過合理的架構，實現高複用，高解耦，可迭代的代碼，並且，在學習的過程當中也明白了爲何說更改客戶需求會殺死一個程序員，做業的小小需求改變均可能須要咱們去重構本身的代碼，面向對象的方式確實使得效率有所提高！

另外一個收穫是jml，uml等和java相關的設計方法和輔助工具等，同時在研討課上也瞭解了一些企業關注的點，對於本身的職業規劃有必定的幫助吧！

總之，整個課程，最大的收穫就是逐步瞭解並學習了面向對象這一思想，而且瞭解瞭如今主流的設計方式就是這種思想，在寫做業的過程當中也確實學習了不少Java的知識，卻是對於架構的設計仍是隻知其一;不知其二，須要繼續學習吧！

（5）建議

如下徹底爲我的見解，不必定具備可實施性，但願客觀看待！

1. 不知道其餘同窗對於互測的態度，可是我我的的感受是兩天不到的時間去研讀其餘同窗的代碼，說實話感受很費力，若是單純的從找bug出發，我可能根本不會去讀代碼，只是會選擇數據測試；這裏費力僅僅體現於有7份代碼，可是同時還有恐怖的OS呢，因此時間或者互測的人數是否有協調的可能性和可實施性呢？
2. 對於每個單元，是否會有一個標程呢（正對萌新和不知所措的選手），而後比對本身的進行進一步的學習（有註釋就最好了）；不過這一學期助教確實很辛苦，須要對OO改革付出巨大精力，先感謝一波付出！那麼下一屆助教呢❓
3. 目前好像是沒建議了，在截止前想到再補吧！