2.代碼分析

UML類圖如下：

UML協(xié)作圖如下：

Statistic分析如下：

Metrics分析如下：

線程角度：由于我本著求穩(wěn)的心態(tài)，在線程通信這方面基本上和第一次作業(yè)一樣，換句話說盡管電梯增加了，每個(gè)請求去哪個(gè)電梯依然是固定的，該用sychronized封裝的地方和上次也沒什么區(qū)別。

架構(gòu)角度：多了調(diào)度類，電梯也存在了繼承關(guān)系，但是由于我所實(shí)現(xiàn)的調(diào)度本身就是一個(gè)靜態(tài)的過程，而且兩種電梯除了look算法有差別外在第六次作業(yè)中基本也沒什么區(qū)別，因此主要的工作量依然是Strategy類中對于兩種look算法的實(shí)現(xiàn)。這里我也確實(shí)是繼承了我第一次作業(yè)的缺點(diǎn)，Strategy類不僅沒有減輕負(fù)擔(dān)反而還來了個(gè)加倍的工作量。其實(shí)這里應(yīng)該對策略類和電梯類的交互進(jìn)行一下重構(gòu)，但是由于本人的懶惰就沒有進(jìn)行。

該架構(gòu)的優(yōu)點(diǎn)：對橫縱向電梯的分離有利于后期的迭代，每個(gè)電梯對應(yīng)各自的請求隊(duì)列從而擁有良好的線程安全性。

該架構(gòu)的缺點(diǎn)：完全采用基準(zhǔn)策略靜態(tài)分配，導(dǎo)致性能與使用自由競爭/其他優(yōu)化方案的架構(gòu)相比確實(shí)差了一些，其他缺點(diǎn)跟第一次一樣。

第七次作業(yè)（動(dòng)靜結(jié)合）

1.架構(gòu)、調(diào)度器與多線程分析

到了第二單元的最后一次作業(yè)，我的目的也變得很簡單了，因?yàn)闊o需考慮后期的迭代了（可以為所欲為了哈），因此唯一的目的就是正確性（捎帶著性能）。第七次作業(yè)可能都會(huì)猜到會(huì)有不同樓座不同樓層的請求了，這就涉及到了中轉(zhuǎn)的過程了，我前兩次作業(yè)犧牲了一部分性能就是為了盡量保證線程的安全性，這次無論如何都不能偷懶了，因?yàn)殡娞菥€程之間是一定會(huì)有交互的。

相對于第六次作業(yè)，第七次作業(yè)主要加入了如下新功能：電梯的屬性增加了，容量和爬樓時(shí)間由常數(shù)變成了可以改變的屬性，除此之外，橫向電梯多了一個(gè)屬性就是開關(guān)門信息，利用一個(gè)1~31的數(shù)字，將其二進(jìn)制的每一位和A~E樓座對應(yīng)，代表著在某些樓座橫向電梯無法開門。不過這些其實(shí)都是可以用正常的方法就可以解決的，最關(guān)鍵的就是這次作業(yè)來了較為隨意的請求，這里就需要對該類請求做出特別的分析。其實(shí)，閱讀指導(dǎo)書可以發(fā)現(xiàn)，只要是不同樓座的請求，都可能會(huì)發(fā)生中轉(zhuǎn)過程。因此我構(gòu)建了一個(gè)SpecialRequest類，繼承官方提供的PersonRequest類，對于讀到的fromBuilding和toBuilding不同的請求，都轉(zhuǎn)化成SpecialRequest類型供調(diào)度器安排，而且SpecialRequest類中還多了一個(gè)屬性就是中轉(zhuǎn)樓層。

這樣整體架構(gòu)就出來了，比第六次多了一個(gè)SpecialRequest類。至于調(diào)度器的變化，這里確實(shí)是第七次作業(yè)最關(guān)鍵的地方：調(diào)度器在讀到PersonRequest的時(shí)候，如果發(fā)現(xiàn)這個(gè)請求的起始和目的樓座不同，那么就會(huì)重新new一個(gè)SpecialRequest對象，復(fù)制過來PersonRequest的所有屬性，同時(shí)計(jì)算需要中轉(zhuǎn)的樓層，根據(jù)目前所有樓層的電梯，在既存在橫向電梯且開關(guān)門信息符合該請求的樓層中選擇距離起始樓層和目的樓層之和最小的，找到中轉(zhuǎn)樓層后電梯在分析請求的目的樓層時(shí)，對于SpecialRequest的目的樓層就不是toFloor，而是transferFloor了。

對于多種電梯的選擇，我依然采用基準(zhǔn)策略，但是在這基礎(chǔ)上根據(jù)自己的理解進(jìn)行了優(yōu)化：在選擇電梯的時(shí)候，速度快容量大的電梯優(yōu)先選擇。采用這樣的策略在請求比較少的時(shí)候和自由競爭的性能差不多，但是在請求比較多的時(shí)候性能如何確實(shí)不太好說了。

如何實(shí)現(xiàn)整個(gè)中轉(zhuǎn)過程呢？這里我采用了動(dòng)靜結(jié)合的方式。調(diào)度器本來只是輸入線程的屬性，但是由于從電梯中出來的請求可能是中轉(zhuǎn)的請求，因此該請求還需要重新分配電梯，因此需要給策略類也配備一個(gè)調(diào)度器，所以當(dāng)中轉(zhuǎn)的乘客出電梯時(shí)候，策略類里會(huì)分析出該乘客目前的起始地和目的地，重新將一個(gè)新的PersonRequest扔進(jìn)調(diào)度器內(nèi)，這樣就做到了靜態(tài)分配電梯，動(dòng)態(tài)調(diào)度中轉(zhuǎn)請求。

在多線程角度看，調(diào)度器的功能之一就是根據(jù)讀進(jìn)來的請求分配電梯，由于調(diào)度器封裝進(jìn)了策略類內(nèi)部，因此策略類的工作并沒有變得特別繁重，而且電梯與電梯之間采用調(diào)度器進(jìn)行溝通連接，線程安全方面也還算可以。但是由于中轉(zhuǎn)請求的特點(diǎn)，電梯線程的結(jié)束條件需要多考慮一下，前兩次作業(yè)電梯線程的結(jié)束條件是輸入線程結(jié)束且本電梯的所有請求處理完畢，可中轉(zhuǎn)請求的特點(diǎn)就是目前用不上的電梯過一段時(shí)間后可能會(huì)使用，因此電梯線程結(jié)束條件就改成了輸入線程結(jié)束且全部電梯的所有請求處理完畢。這樣就又導(dǎo)致了一個(gè)問題，不能光在輸入線程結(jié)束后喚醒所有空閑的線程，在電梯線程結(jié)束后也要喚醒全部線程，否則輸入線程提前結(jié)束，請求還沒有處理完，會(huì)出現(xiàn)先喚醒再沉睡的錯(cuò)誤（當(dāng)然這里的問題因代碼而異）。

2.代碼分析

UML類圖如下：

UML協(xié)作圖如下：

Statistics分析如下：

Metrics分析如下：

根據(jù)上圖可以看出，可拓展性幾乎沒有了，因此多個(gè)類的復(fù)雜度很高，而Strategy和Schedule兩個(gè)類正是整個(gè)電梯調(diào)度過程的核心類，復(fù)雜度過高對debug和bug的修復(fù)確實(shí)會(huì)有很大影響。

該架構(gòu)的好處：線程安全性高，動(dòng)靜結(jié)合的中轉(zhuǎn)過程使得其既有基準(zhǔn)策略的線程安全，又在性能上有了一定的優(yōu)化。

該架構(gòu)的缺點(diǎn)：真的不能再迭代了，再來其他電梯或策略是真的寫不下去了；在性能上不太穩(wěn)定，相比于自由競爭會(huì)差一些。

同步塊和鎖的分析

由于本人三次作業(yè)都在盡量避免線程沖突，優(yōu)化方案也都盡量在靜態(tài)過程中進(jìn)行，因此在同步塊和鎖的這方面確實(shí)思考的不夠多。

首先就是輸出類，官方包提供的輸出類是線程不安全的，而且TimableOutput相當(dāng)于一個(gè)全局變量，如果有多個(gè)位置同時(shí)調(diào)用它的println方法的時(shí)候會(huì)發(fā)生一些奇怪的事情導(dǎo)致時(shí)間戳不遞增。
因此，根據(jù)其他同學(xué)的想法，利用synchronized將TimableOutput.println封裝成同步方法。

其次還需要考慮的地方就是ArrayList本身是線程不安全的，所以如果兩個(gè)地方同時(shí)對ArrayList進(jìn)行增刪操作的時(shí)候可能會(huì)發(fā)生異常，因此，前兩次作業(yè)僅僅是用synchronized鎖住了特定的數(shù)組，這樣可以避免該數(shù)組同時(shí)remove和add。等到了第七次作業(yè)，我采用了利用Collections.synchronizedList方法使數(shù)組變成線程安全的(代碼如下），因?yàn)橛捎谝恍﹥?yōu)化方法，需要對數(shù)組內(nèi)部的元素進(jìn)行排序，然而同時(shí)數(shù)組也可能會(huì)增刪元素，因此我直接利用該方法讓ArrayList變成線程安全的可以免除后顧之憂，但是性能可能會(huì)略有下降。

        for (int i = 0; i < 10; i++) {
            Elevators[i] = new ArrayList<>();
            Collections.synchronizedList(Elevators[i]);
        }

互測/自測的策略+bug分析

跟第一單元相比，第二單元的輸入如果手動(dòng)構(gòu)造會(huì)很麻煩，但是格式非常固定，由于我還不會(huì)什么高級語言，所以拿C隨便生成了一些數(shù)據(jù)。比如說第五次作業(yè)，只要按照指導(dǎo)書限定好每個(gè)數(shù)據(jù)（時(shí)間，樓層，樓座，ID)的范圍，就能夠生成很多請求；第六、七次作業(yè)只需要添加一些可以生成增加電梯的隨機(jī)輸出，再豐富一些細(xì)節(jié)就可以了。不過我不會(huì)寫評測機(jī)來驗(yàn)證我的代碼的正確性，所以在生成數(shù)據(jù)的時(shí)候，一般只生成五六行，然后通過肉眼來觀察過程的正確性。最后生成50-100行的數(shù)據(jù)來觀察代碼是否會(huì)出現(xiàn)TLE或者RA等錯(cuò)誤。如果產(chǎn)生了TLE這樣的錯(cuò)誤，我一般會(huì)刪減一些代碼，盡量將錯(cuò)誤鎖定在幾個(gè)特定輸入上，然后就開始捋自己的代碼執(zhí)行過程，這個(gè)過程確實(shí)是低效的，但對我來說是不得不做的。至于判斷是CTLE是RTLE，由于本人不會(huì)寫評測機(jī)，因此確實(shí)不容易確定，只能通過IDEA的debug功能和在各個(gè)位置進(jìn)行print來判斷線程是否結(jié)束，哪里陷入死循環(huán)等等。至于bug時(shí)而出現(xiàn)時(shí)而不出現(xiàn)的問題，我也只能多做嘗試，盡量保存每次出現(xiàn)bug的輸入輸出，沒有什么巧妙的辦法。

互測的時(shí)候，我是利用自動(dòng)生成數(shù)據(jù)+構(gòu)造刁鉆數(shù)據(jù)的方法，自動(dòng)生成數(shù)據(jù)一般比較隨機(jī)，刁鉆數(shù)據(jù)一般是如下幾種：某種相同請求在同一時(shí)刻大量出現(xiàn)、同一座（層）樓有各種方向的請求、每層樓都有大量請求等等。由于不像第一單元利用肉眼就能看出對錯(cuò)，況且本地輸出和評測機(jī)輸出很有可能不一致，所以這幾次互測我把每個(gè)數(shù)據(jù)都直接交到評測機(jī)上了。

對于產(chǎn)生的bug，主要是輸出類線程不安全的問題，也是因?yàn)閷懲甑谖宕巫鳂I(yè)后，清明節(jié)假期期間沒太思考，既沒看討論區(qū)也沒看水群，所以這里的問題給忽略了。

心得體會(huì)和反思

兩個(gè)單元的學(xué)習(xí)確實(shí)感覺收獲了很多。對于面向?qū)ο蟮睦斫飧由钊耄嫦驅(qū)ο蟮挠⑽氖荗bject-Oriented，根據(jù)我的理解，Object其實(shí)說白了就是東西，對于程序員來說，在用代碼描繪某件抽象的過程時(shí)，我們需要從中構(gòu)建出實(shí)體出來，換句話說要對代碼的功能和變量進(jìn)行分類，對于一個(gè)需求，在學(xué)C語言程序設(shè)計(jì)的時(shí)候我們可能更加關(guān)注的是數(shù)據(jù)結(jié)構(gòu)和運(yùn)行過程，而對于面向?qū)ο?，我們還要關(guān)注的有在實(shí)現(xiàn)需求的過程中，整個(gè)流程是由哪幾個(gè)東西來干，每個(gè)東西有什么特點(diǎn)、能干什么事情，東西與東西之間有什么聯(lián)系。當(dāng)然，我的理解可能還很膚淺甚至是錯(cuò)誤的，但是，我在學(xué)習(xí)OO課的過程中，確確實(shí)實(shí)能夠感受到自己的編程思想在發(fā)生一些轉(zhuǎn)變。

不過，需要提升的地方還有很多，比如說架構(gòu)設(shè)計(jì)和代碼實(shí)現(xiàn)上，盡管現(xiàn)在拿來題先開始設(shè)計(jì)架構(gòu)而不是直接敲鍵盤了，但是設(shè)計(jì)到實(shí)現(xiàn)的過程還很艱難，感覺設(shè)計(jì)的時(shí)候考慮的東西還不夠周到，導(dǎo)致實(shí)現(xiàn)的時(shí)候很多地方都得重新構(gòu)思。其次，關(guān)于每個(gè)功能的代碼實(shí)現(xiàn)，代碼總是超過限制的行數(shù)，覺得自己可能在框架上是面向?qū)ο蟮?/strong>，但是在具體敲鍵盤的時(shí)候依然是面向過程的，希望在以后的學(xué)習(xí)過程中能夠提升自己面向?qū)ο蟮哪芰?，能夠更好的利用面向?qū)ο蟮乃枷肜斫馐澜纭?/p>

除此之外，對于實(shí)驗(yàn)課我也有一些反思。每次實(shí)驗(yàn)課助教們都在對我們的作業(yè)架構(gòu)進(jìn)行一定的提示，所以實(shí)驗(yàn)課代碼確實(shí)是我們應(yīng)該借鑒和學(xué)習(xí)的，但是這兩個(gè)單元我都忽視了實(shí)驗(yàn)代碼的重要性，導(dǎo)致一直在堆自己的*山。但是，不得不說，我經(jīng)常看不太懂實(shí)驗(yàn)代碼，盡管實(shí)驗(yàn)代碼的架構(gòu)很清晰巧妙，但是我還需要很多時(shí)間去理解。所以很多時(shí)候自己的爛代碼就像是自己的孩子，而實(shí)驗(yàn)代碼就像是別人家的孩子，不管別人家的孩子多么優(yōu)秀，我只愿意呵護(hù)關(guān)心自己的孩子。我這個(gè)比喻并不恰當(dāng)，但是確實(shí)希望以后能夠多理解理解實(shí)驗(yàn)代碼，畢竟實(shí)驗(yàn)代碼的架構(gòu)和實(shí)現(xiàn)方式確實(shí)是教科書式的，如果能熟練應(yīng)用在自己的作業(yè)中會(huì)更好。