2.代碼分析

UML類圖如下：

UML協(xié)作圖如下：

Statistic分析如下：

Metrics分析如下：

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

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

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

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

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

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

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

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

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

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

如何實(shí)現(xiàn)整個(gè)中轉(zhuǎn)過程呢？這里我采用了動(dòng)靜結(jié)合的方式。調(diào)度器本來(lái)只是輸入線程的屬性，但是由于從電梯中出來(lái)的請(qǐng)求可能是中轉(zhuǎn)的請(qǐng)求，因此該請(qǐng)求還需要重新分配電梯，因此需要給策略類也配備一個(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)請(qǐng)求。

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

2.代碼分析

UML類圖如下：

UML協(xié)作圖如下：

Statistics分析如下：

Metrics分析如下：

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

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

該架構(gòu)的缺點(diǎn)：真的不能再迭代了，再來(lái)其他電梯或策略是真的寫不下去了；在性能上不太穩(wěn)定，相比于自由競(jìng)爭(zhēng)會(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í)對(duì)ArrayList進(jìn)行增刪操作的時(shí)候可能會(huì)發(fā)生異常，因此，前兩次作業(yè)僅僅是用synchronized鎖住了特定的數(shù)組，這樣可以避免該數(shù)組同時(shí)remove和add。等到了第七次作業(yè)，我采用了利用Collections.synchronizedList方法使數(shù)組變成線程安全的(代碼如下），因?yàn)橛捎谝恍﹥?yōu)化方法，需要對(duì)數(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]);
        }

互測(cè)/自測(cè)的策略+bug分析

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

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

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

心得體會(huì)和反思

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

不過，需要提升的地方還有很多，比如說(shuō)架構(gòu)設(shè)計(jì)和代碼實(shí)現(xiàn)上，盡管現(xiàn)在拿來(lái)題先開始設(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>

除此之外，對(duì)于實(shí)驗(yàn)課我也有一些反思。每次實(shí)驗(yàn)課助教們都在對(duì)我們的作業(yè)架構(gòu)進(jìn)行一定的提示，所以實(shí)驗(yàn)課代碼確實(shí)是我們應(yīng)該借鑒和學(xué)習(xí)的，但是這兩個(gè)單元我都忽視了實(shí)驗(yàn)代碼的重要性，導(dǎo)致一直在堆自己的*山。但是，不得不說(shuō)，我經(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ì)更好。