今天看的是作者的第三次提交拳喻，這次提交并沒有添加哪些實質性的功能乙墙，而是重構了一些類和方式的命名，以及對現(xiàn)有的項目結構做了一些調整法牲。之前的實現(xiàn)方式依然存在耦合比較多的情況并且命名方式比較模糊额衙，新的實現(xiàn)方式則是創(chuàng)建了兩個新的接口RequestMatcher和ResponseHandler饮焦，這兩個接口分別代表的是輸入時參數(shù)的匹配器與返回時的結果處理器。從很直觀的看入偷，這次改動會讓一個從沒看過之前代碼的人追驴，可以簡單的通過代碼的架構和類的命名來看懂這些類的作用以及如何使用這個項目械哟。同時疏之，把之前在MocoServer中的兩個方法: withContent()和withUri()放在了Moco類中脑豹，并重命名研叫。
public RequestSetting withContent(String requestContent) {
return new ContentRequestSetting(this, requestContent);
}
public RequestSetting withUri(String uri) {
return new UriRequestSetting(this, uri);
}
public static RequestMatcher eqUri(String uri) {
return new UriRequestMatcher(uri);
}
public static RequestMatcher eqContent(String content) {
return new ContentRequestMatcher(content);
}
我認為這兩個方法確實不應該屬于一個服務器類里脱羡，暫時放在了這個程序的入口Moco我覺得只是暫時的策略处铛，后期一定會把這兩個方法重構在其他地方赖晶。
前面提到的RequestMatcher有兩個實現(xiàn)類矫渔，分別是ContentRequestMatcher類和UriRequestMatcher類啃奴，他們替代了前有的RequestSetting實現(xiàn)類腊满。并且作者將之前并沒有實現(xiàn)的match中的邏輯實現(xiàn)了扯旷，做到了根據(jù)匹配Request中的參數(shù)來組裝他的Response拯爽。談到組裝Response，作者在本次提交中钧忽，將原有的實現(xiàn)方式（在MocoHandler全部包辦）毯炮，改成了把writeToResponse()方法分離出來寫進ResponseHandler的方式逼肯，再由ResponseHandler調用不同實現(xiàn)類中的不同的writeContent()方法，這樣實現(xiàn)好處在于桃煎，我可以根據(jù)調用response()方法時篮幢，傳入的參數(shù)不同而采用不同的策略。
這一次的提交为迈，總體給人的感覺就是更加清晰了三椿，無論是項目的結構還是作者的思路，都讓我一個局外人看的更加清楚葫辐。
