今天看的是2012.11.02那天的三次提交弓柱，第一次提交加了一些TODO事項，記下了作者接下來要做什么驻售。第二次提交在README當中，增加了一些文檔更米。比較重要的是第三次提交欺栗，這次提交新加了一個功能，支持在request中傳入xpath作為參數(shù)征峦。但是代碼結(jié)構(gòu)沒有變化迟几，所以根據(jù)以前的Uri和Stream的實現(xiàn)方式，這一次也有跡可循栏笆。
server.request(eq(xpath("/request/parameters/id/text()"), "1")).response("foo");
server.request(eq(xpath("/request/parameters/id/text()"), "2")).response("bar");
同樣的类腮，定義了一個XPath類，該類的構(gòu)造方法就是傳入一個xpath字符串蛉加，創(chuàng)建一個xpath表達式蚜枢。通過xpath方法來得到這個對象，傳入eq()方法當中针饥，得到這個項目中目前為止的第三種matcher厂抽，XPathRequestMatcher。
private XPathExpression xPathExpression;
public XPath(String xpath) {
XPathFactory xPathfactory = XPathFactory.newInstance();
javax.xml.xpath.XPath target = xPathfactory.newXPath();
try {
xPathExpression = target.compile(xpath);
} catch (XPathExpressionException e) {
throw new RuntimeException(e);
}
}
這次提交中丁眼，還重構(gòu)了一部分代碼筷凤，由于ContentMatcher中有一部分代碼是所有Matcher公共的代碼，所以作者把這部分代碼提取到一個抽象類中户盯，其他的Matcher實現(xiàn)類來繼承這個抽象類以繼承公共代碼嵌施，私有化的代碼就可以在自己的類中去實現(xiàn)饲化。
這個項目看到這兒，這個代碼給我的感覺就是結(jié)構(gòu)非常的清晰吗伤，可擴展性非常強（因為作者在不停的擴展著自己的項目來展示他的代碼有多那么強大的可擴展性）吃靠。那究竟是為什么這份代碼可擴展性這么好呢？我認為有三個原因足淆。
一巢块、函數(shù)式代碼
作者的代碼都是函數(shù)式的代碼，非常易懂巧号。
二族奢、清晰地命名
代碼的類和函數(shù)的命中都非常的清楚，光看命名就可以對他的作用猜出一二丹鸿。
三越走、類和函數(shù)的粒度小
類和函數(shù)的功能都非常的小，每一個函數(shù)只做一件事情靠欢，這樣當代碼需要擴展時廊敌，只需要找到功能的前后階段，在前后階段加入代碼即可门怪。
