加餐4講15新需求破壞了代碼

2021-02-0213:03大小13:03大小可能因為新的需求到來，不經(jīng)意間就會破壞。一個有生命力的代碼不會保持靜止，新的需求總會到來，所以，了。PUT/chapter/{chapterId}/reviewPUT/chapter/{chapterId}/review在這個設計里，將章節(jié)（haptr）的審核（rviw）當作了一個資源。在創(chuàng)建章節(jié)的時通過，就相當于刪除了這個資源。classclassChapterServicepublicvoidapprove(finalChapterIdchapterId)publicvoidreject(finalChapterIdchapterId)顧名思義，approve函數(shù)對應著審核通過，而rjt有一個狀態(tài)字段，標識現(xiàn)在章節(jié)處于什么樣的狀態(tài)。章節(jié)是待審核、審核通過，還是審核不通過，就是通過這個字段標記出來的。classclassChapterprivateStatusstatus=publicvoid{this.status=publicvoid{this.status=按捺不住自己蠢蠢欲動的雙手，準備寫代碼了呢？來一個新需求，增加一個新接口，對于很多人來說，這是一種常規(guī)操作。但。的業(yè)務。所以，我們必須對接口的調(diào)整慎之又慎。最好的辦法就是從源頭進行限制，也就是說，當駁回。所以，我們完全可以復用原來的審核不通過接口。既然是復用接口，所有的變化就全部都是內(nèi)部變化了，我們可以根據(jù)章節(jié)當前的狀態(tài)進行判斷，設置相應的狀態(tài)。具體到代碼上，我們既不需要增加駁回的接口，也不需要增加駁回的服務，只需要在Chaptr代碼結(jié)構大體如下所示：classclassChapterprivateStatusstatus=publicvoidreject()if(status=={this.status=Status.REJECTED;return;if(status==Status.APPROVED)們是否可以將二者統(tǒng)一起來呢？也就是說，都按照審核不通過來處理呢？classclassChapter章節(jié)privateChapterIdprivateStringprivateStringprivateStatusprivateZonedDateTimeprivateStringprivateStringprivateZonedDateTimeclassclassChapterprivateZonedDateTime4系統(tǒng)中最穩(wěn)定的部分。到Chaptr這個類里面。不放在Chapter這個類里面，那要放到哪呢？很顯然，這里少了一個模型，一個關于調(diào)度的模型。我們只要增加一個新的模型，讓它和Chapter關聯(lián)在一起就好了：classclassChapterSchedule{privateChapterIdchapterId;privateZonedDateTime5們的核心模型Chapter在這個過程中是保持不變的。來說，深入理解單一職責原則是非常必要的。就結(jié)束了嗎？我們可能暫時還不能停下來。個時間就會變。classclassChapterprivateZonedDateTime4到這里，估計有些人已經(jīng)懵了。前面我們辛辛苦苦地討論，為的就是不在Chapter里增加應該分開了?；蛟S你還有一個疑問，我們難道不能直接用submittdAt不行。因為調(diào)度時間可能與具體提交的時間有差異。我舉個例子，因為某種原因，系統(tǒng)宕機了，啟動之后，調(diào)度任務執(zhí)行，這時可能已經(jīng)過了調(diào)度時間很多了，但這個時候提交章節(jié)，它的